2024-30983. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information

Term	Meaning
AI	Artificial Intelligence.
ANSI	American National Standards Institute.
AR	Augmented Reality.
ARRA	American Recovery and Reinvestment Act of 2009.
ASTP/ONC	Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology.
CISA	Cybersecurity & Infrastructure Security Agency.
CMS	Centers for Medicare & Medicaid Services.
CPG	Cybersecurity Performance Goal.
Department or HHS	Department of Health and Human Services.
EHR	Electronic Health Record.
E.O.	Executive Order.
ePHI	Electronic Protected Health Information.
FDA	Food & Drug Administration.
FISMA	Federal Information Security Modernization Act.
FTC	Federal Trade Commission.
Health IT	Health Information Technology.
( print page 902)
HIPAA	Health Insurance Portability and Accountability Act of 1996.
HITECH Act	Health Information Technology for Economic and Clinical Health Act of 2009.
ICR	Information Collection Request.
IIHI	Individually Identifiable Health Information.
IT	Information Technology.
MFA	Multi-factor Authentication.
NAICS	North American Industry Classification System.
NCVHS	National Committee on Vital and Health Statistics.
NIST	National Institute of Standards and Technology.
NPRM	Notice of Proposed Rulemaking.
OCR	Office for Civil Rights.
OMB	Office of Management and Budget.
ONC	Office of the National Coordinator for Health Information Technology.
PHI	Protected Health Information.
PRA	Paperwork Reduction Act of 1995.
PSAO	Pharmacy Services Administration Organizations.
RFA	Regulatory Flexibility Act.
RIA	Regulatory Impact Analysis.
SBA	Small Business Administration.
SRMA	Sector Risk Management Agency.
SSA	Social Security Act of 1935.
UMRA	Unfunded Mandates Reform Act of 1995.
VR	Virtual Reality.

II. Statutory Authority and Regulatory History

A. Statutory Authority and History

1. Health Insurance Portability and Accountability Act of 1996 (HIPAA)

In 1996, Congress enacted HIPAA ^[28] to reform the health care delivery system to “improve portability and continuity of health insurance coverage in the group and individual markets” ^[29] and “to simplify the administration of health insurance.” ^[30] Through subtitle F of HIPAA, Congress amended title XI of the Social Security Act of 1935 (SSA) by adding part C, entitled “Administrative Simplification.” ^[31] A primary purpose of part C is to improve the Medicare and Medicaid programs and “the efficiency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of uniform standards and requirements for the electronic transmission of certain health information.” ^[32]

Congress recognized that the development of a health information system that enabled the electronic transmission of IIHI as required by HIPAA would pose risks to the privacy of confidential health information and viewed individual privacy, confidentiality, and data security as critical to support the shift from a paper-based recordkeeping system for health information to a digital one.^[33] Congress intended for the law to enhance individuals' trust in health care providers, which required that the law provide additional protection for the confidentiality of IIHI. As described by a Member of Congress at the time of the law's passage: “[t]his standardization, however, accelerates the creation of large databases containing personally identifiable information. All this information is transmitted over electronic networks. We need to be very careful about how safe and secure that information is from prying eyes. Some of it may be extremely sensitive and could be used in a malicious or discriminatory manner.” ^[34] Moreover, Congress considered that health care reform required an approach that would not compromise privacy as health information became more accessible.^[35]

Congress applied the Administrative Simplification provisions directly to three types of persons referred to in regulation as covered entities: health plans, health care clearinghouses, and health care providers who transmit information electronically in connection with a transaction for which HHS has adopted a standard.^[36] Under HIPAA, covered entities are required to maintain reasonable and appropriate administrative, physical, and technical safeguards ^[37] to: (1) ensure the integrity and confidentiality of information; ^[38] (2) protect against any reasonably anticipated threats or hazards to the security or integrity of the information and unauthorized uses or disclosures of the information; ^[39] and (3) otherwise ensure compliance with HIPAA by the officers and employees of covered entities.^[40]

HIPAA required the Secretary to adopt uniform standards “to enable health information to be exchanged electronically.” ^[41] Congress also directed the Secretary to, among other things, adopt standards for the security of IIHI.^[42] The statute also directed the Secretary to adopt initial security standards within 18 months of its ( print page 903) enactment.^[43] In adopting security standards for health information, HIPAA requires the Secretary to consider all of the following: ^[44]

• The technical capabilities of record systems used to maintain health information.
• The costs of security measures.
• Training for persons who have access to health information.
• The value of audit trails in computerized record systems.
• The needs and capabilities of small health care providers and rural health care providers.^[45]

Congress contemplated that the Department's rulemaking authorities under HIPAA would not be static. In fact, Congress specifically built in a mechanism to adapt such regulations as technology and health care evolve, directing the Secretary to review and adopt modifications to the Administrative Simplification standards, including the security standards, as determined appropriate, but not more frequently than once every 12 months.^[46] That statutory directive complements the Secretary's general rulemaking authority to make and publish such rules and regulations as may be necessary to the efficient administration of the functions with which the Secretary is charged.^[47] The Secretary may adopt either a standard developed, adopted, or modified by a standard setting organization that relates to a standard that the Secretary is authorized or required to adopt under the Administrative Simplification provisions, or a standard that is different if the different standard will substantially reduce administrative costs to health care providers and health plans.^[48] If no standard has been adopted by any standard setting organization, the Secretary shall rely on the recommendations of the National Committee on Vital and Health Statistics (NCVHS) and consult with Federal and State agencies and private organizations.^[49]

2. Health Information Technology for Economic and Clinical Health (HITECH) Act

On February 17, 2009, Congress enacted the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act), part of the American Recovery and Reinvestment Act of 2009 (ARRA),^[50] promoting the nationwide adoption and standardization of health information technology (health IT) to support the electronic sharing of clinical data. The HITECH Act created financial incentives for health IT use among health care practitioners by providing funding for investing in health IT infrastructure, purchasing certified electronic health records (EHRs), and training on and the dissemination of best practices to integrate health IT.^[51] The Purpose statement of an accompanying House of Representatives report ^[52] on the Energy and Commerce Recovery and Reinvestment Act ^[53] recognizes that widespread health IT adoption “has the potential to ameliorate many of the quality and efficiency problems endemic to our health care system.” Congress also understood that “[e]nsuring the privacy and security of electronic health information is critical to the success” of this immense effort to promote health IT adoption.^[54] As a result, the HITECH Act also introduced substantial changes to the HIPAA regulations by mandating stronger safeguards for the privacy and security of ePHI.^[55]

The HITECH Act's security requirements focused on safeguarding an individual's health information while allowing covered entities to rapidly adopt new technologies to improve the quality and efficiency of patient care.^[56] Specifically, the HITECH Act extends the application of the Security Rule's provisions on administrative, physical, and technical safeguards and documentation requirements to business associates of covered entities, making those business associates subject to civil and criminal liability for violations of the Security Rule.^[57] The HITECH Act also requires existing business associate agreements to incorporate new security requirements.^[58] Additionally, the HITECH Act requires the Secretary to regularly issue guidance on the most effective and appropriate technical safeguards.^[59]

In enacting the HITECH Act, Congress affirmed that the existing HIPAA Rules were to remain in effect to the extent that they are consistent with the HITECH Act and directed the Secretary to revise the HIPAA Rules as necessary for consistency with the HITECH Act.^[60] Congress confirmed that the new law was not intended to have any effect on authorities already granted under HIPAA to the Department, including part C of title XI of the SSA.^[61] Thus, Congress affirmed the Secretary's ongoing rulemaking authority to modify the Security Rule's standards and implementation specifications as often as every 12 months when appropriate, including to strengthen security protections for IIHI.

In 2021, the HITECH Act was amended to require the HHS Secretary to further encourage regulated entities to bolster their cybersecurity practices.^[62] The amendment requires the Department to consider certain recognized security practices of regulated entities when making determinations relating to certain Security Rule compliance and enforcement activities.^[63]

B. Regulatory History

The Security Rule requires regulated entities to implement administrative, physical, and technical safeguards to ( print page 904) protect ePHI.^[64] Specifically, regulated entities must ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit; ^[65] protect against reasonably anticipated threats or hazards to the security or integrity of the information ^[66] and reasonably anticipated impermissible uses or disclosures; ^[67] and ensure compliance by their workforce.^[68]

1. 1998 Security Rule Notice of Proposed Rulemaking

The Administrative Simplification provisions of HIPAA instructed the Secretary to adopt several standards concerning electronic transmission of health information, including those for the security of health information.^[69] In accordance with these provisions, the Department published the Security and Electronic Signature Standards; Proposed Rule (“1998 Proposed Rule”) on August 12, 1998.^[70]

In support of developing the national standards mandated under HIPAA's Administrative Simplification provisions, the Secretary, with significant input from the health care industry, defined a set of principles for guiding choices for the standards to be adopted by the Secretary.^[71] The principles were based on direct specifications in HIPAA and also took the purpose of the law and generally desirable principles into account. Based on this work, the Department proposed that each HIPAA standard should be clear and unambiguous but technology neutral, improve the efficiency and effectiveness of the health care system, meet the needs of covered entities related to ease of use and affordability of adoption, and maintain consistency or alignment with other HIPAA standards adopted by an organization accredited by the American National Standards Institute (ANSI) and using the ANSI process for adopting such standards.^[72]

In describing its general approach to the 1998 Proposed Rule, the Department defined the security standard as a set of requirements with implementation features that covered entities must include in their operations to assure the security of individuals' ePHI.^[73] The security standard was based on three basic concepts that were derived from the Administrative Simplification provisions of HIPAA and consistent with the characteristics the Department identified as appropriate for all HIPAA Rules.^[74] First, the standard should be comprehensive and coordinated to address all aspects of security. Second, it should be scalable, so that it could be effectively implemented by covered entities of all types and sizes. Third, it should not be linked to specific technologies, allowing covered entities the flexibility to make use of future technology advancements.^[75]

The 1998 Proposed Rule included four categories of requirements that a covered entity would have to address to safeguard the confidentiality, integrity, and availability of ePHI. They were as follows:

• Administrative procedures.
• Physical safeguards.
• Technical security services.
• Technical mechanisms.

The implementation specifications described some of the requirements in greater detail, based on our determination regarding the level of instruction necessary to implement such requirements.^[76] The Department viewed all categories as equally important.^[77]

The proposed standard did not address the extent to which a covered entity should implement the specifications.^[78] Instead, the Department proposed to require that each covered entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its business requirements. The Department believed that this approach would leave a significant amount of flexibility for covered entities and balance the needs of securing health data against risk with the economic cost of doing so.^[79]

2. 2003 Final Rule

The Department issued the final Security Rule ^[80] on February 20, 2003 (“2003 Final Rule”). In accordance with the Administrative Simplification provisions of HIPAA, the 2003 Final Rule adopted standards for the security of ePHI to be implemented by covered entities.

The Department reiterated the purposes and guiding principles it articulated in the 1998 Proposed Rule and repeated that the protection of the privacy of information depends in large part on the existence of security measures to protect that information.^[81] The Department noted that there were still no standard measures in the health care industry that address all aspects of the security of ePHI while it is being stored or during the exchange of that information between entities.^[82] The Department explained that the use of the security standards would improve the Medicare and Medicaid programs, other Federal health programs and private health programs, and the effectiveness and efficiency of the health care industry in general by establishing a level of protection for ePHI.^[83]

Provisions of the 2003 Final Rule did not mirror the 1998 Proposed Rule; rather, the Department finalized only certain changes. The Department noted, for example, that to maintain consistency with the use of terms as they appear in the statute and other previously released HIPAA Rules ( i.e., the HIPAA Privacy and Transactions Rules), it was changing some terminology from the 1998 Proposed Rule, replacing the terms “requirement” with “standard” and “implementation feature” with “implementation specification.” ^[84]

According to the Department, the comments received in response to the 1998 Proposed Rule overwhelmingly validated its basic assumptions that the covered entities were so varied in terms of installed technology, size, resources, and relative risk, that it would be impossible to dictate a specific solution or set of solutions that would be usable by all covered entities.^[85] Similarly, we received numerous comments expressing the view that the security standards should not be overly prescriptive because the speed with which technology is evolving could make specific requirements obsolete and might in fact deter technological progress. Accordingly, the Department framed the standards in the 2003 Final Rule in terms that were as generic as possible and that could generally be met through a variety of approaches or technologies.^[86] The standards, we ( print page 905) explained, do not allow organizations to make their own rules, only their own technology choices.^[87]

We also recognized that entities could minimize risk through their security practices, but likely could never completely eliminate all risk. In the preamble to the 2003 Final Rule, the Department acknowledged that there is no such thing as a totally secure system that carries no risks to security.^[88] The Department opined that Congress' intent in the use of the word “ensure” in section 1173(d) of the SSA was to set an exceptionally high goal for the security of ePHI. However, we also recognized that Congress anticipated that some trade-offs would be necessary, and that “ensuring” protection did not mean doing so without any regard to the cost.^[89] As such, the Department explained that we expected a covered entity to protect that information to the best of its ability.^[90] Thus, a covered entity would be expected to balance the identifiable risks to and vulnerabilities of ePHI with the cost of various protective measures, while also taking into consideration the size, complexity, and capabilities of the covered entity.^[91]

In the 2003 Final Rule, the Department introduced the concept of “addressable” implementation specifications, which it distinguished from “required” implementation specifications. The goal was to provide covered entities with even more flexibility.^[92] While none of the implementation specifications were optional, designating some of the implementation specifications as addressable provided each covered entity with the ability to determine whether certain implementation specifications were reasonable and appropriate safeguards for that entity, based on its risk analysis, risk mitigation strategy, previously implemented security measures, and the cost of implementation.^[93]

3. 2009 Delegation of Authority

On October 7, 2003, the Secretary delegated authority for administering and enforcing the Security Rule to the Administrator of the Centers for Medicare & Medicaid Services (CMS).^[94] The Secretary issued a notice on August 4, 2009, superseding the previous delegation and replacing it with a delegation authority to the Director of OCR effective July 27, 2009.^[95]

4. 2013 Omnibus Rulemaking

Following the enactment of the HITECH Act, the Department issued an NPRM, entitled “Modifications to the HIPAA Privacy, Security, and Enforcement Rules Under the Health Information Technology for Economic and Clinical Health [HITECH] Act” (“2010 Proposed Rule”),^[96] to propose implementation of certain HITECH Act requirements. In the 2010 Proposed Rule, the Department noted that it had not amended the Security Rule since 2003.^[97] We further explained that information gleaned from contact with the public since that time, OCR's enforcement experience, and technical corrections needed to eliminate ambiguity provided the impetus for the Department's actions to propose certain regulatory changes beyond those required by the HITECH Act.^[98]

In 2013, the Department issued the final rule “Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health [HITECH] Act and the Genetic Information Nondiscrimination Act, and Other Modifications to the HIPAA Rules” (“2013 Omnibus Rule”),^[99] which implemented applicable provisions of the HITECH Act to strengthen security protections for individuals' health information maintained in EHRs.

For example, the Department modified the Security Rule to implement the HITECH Act's provisions that extended direct liability for compliance with the Security Rule to business associates.^[100] We explained that before the enactment of the HITECH Act, the Security Rule did not directly apply to business associates of covered entities. The HITECH Act extended the application of the Security Rule's administrative, physical, and technical safeguards requirements, as well as the rule's policies and procedures and documentation requirements, to business associates in the same manner as the requirements apply to covered entities, making those business associates civilly and criminally liable for violations of the Security Rule.^[101] The Department noted that the Security Rule requires a covered entity to establish business associate agreements that obligate business associates to implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the ePHI that they create, receive, maintain, or transmit on behalf of the covered entity.^[102] Accordingly, we reasoned that business associates and subcontractors should already have security practices in place that comply with the Security Rule, or require only modest improvement to come into compliance with the Security Rule requirements.^[103] Like the 2003 Final Rule,^[104] the 2013 Omnibus Rule highlighted that the Security Rule was designed to be technology neutral and scalable and reiterated that regulated entities have the flexibility to choose security measures appropriate for their size, resources, and the nature of the security risks they face.^[105] Accordingly, regulated entities have the flexibility to choose appropriate security measures considering their size, capabilities, the costs of the specific security measures, and the operational impact, enabling them to reasonably implement the standards of the Security Rule.

The Department also adopted technical revisions to 45 CFR 164.306(e) to clarify that regulated entities must review and modify security measures as needed to ensure reasonable and appropriate protection of ePHI, and update documentation of security measures accordingly.^[106]

Finally, because the HITECH Act made business associates directly liable for compliance with the Security Rule, the 2013 Omnibus Rule modified the Security Rule to clarify that a covered entity is not required to obtain satisfactory assurance from a business associate that is a subcontractor that the subcontractor will appropriately safeguard its ePHI. Rather, the business ( print page 906) associate of the covered entity must obtain the required satisfactory assurances from the subcontractor to protect the security of ePHI.^[107]

III. Justification for This Proposed Rulemaking

HIPAA and the HIPAA Rules promote access to high-quality and effective health care by establishing standards for the security of ePHI. The standards, when implemented appropriately by regulated entities, protect the confidentiality, integrity, and availability of individuals' health information. Such protections promote the electronic transmission of PHI through a national health information system. To ensure access to high-quality health care services, regulated entities must assure their customers ( e.g., individuals, health care providers, and health plans) of the security of the sensitive and confidential health information the regulated entities electronically create, receive, maintain, or transmit.

As discussed above, the Security Rule carefully balances the benefits of safeguarding against security risks with the burdens of implementing protective measures by permitting regulated entities to consider several factors, including costs and available technology for preventing and mitigating security risks,^[108] when determining which security measures are reasonable and appropriate for protecting the security of individuals' ePHI.^[109]

For example, the Security Rule requires that a regulated entity implement policies and procedures to limit physical access to its electronic information systems and the facilities in which they are housed, while ensuring that users who are authorized to access such information systems and facilities are permitted to do so.^[110] The implementation specifications associated with this standard only address the need for operationalized policies and procedures related to specific aspects of physical security.^[111] They do not dictate the specifics of such policies and procedures because we recognize that the nature of the physical safeguards should depend on the type of regulated entity, its size, its level of access to ePHI, and a number of other factors.

Since the Security Rule's promulgation in 2003, the environment in which health care is provided and in which regulated entities operate has changed significantly, including transformative changes in how regulated entities create, receive, maintain, and transmit ePHI. For example, as of 2021, almost 80 percent of physician offices and 96 percent of hospitals had adopted certified EHRs.^[112] The use of health IT, including EHRs (certified or otherwise), has led to enormous advancements in the fields of medicine and public health, not only improving outcomes for individuals, but also assisting in addressing the social, economic, and environmental factors that affect health on an individual and community level.^[113] And the electronic exchange of health information, spurred by HIPAA, the HITECH Act, and the 21st Century Cures Act (“Cures Act”),^[114] has enabled regulated entities and others to more quickly and efficiently share individuals' health information, increasing the quality and efficiency of health care, increasing patient engagement, and reducing administrative burden.^[115] However, the widespread use of health IT systems makes it even more critical for regulated entities, regardless of their size or location, to fully assess the risks and vulnerabilities to ePHI and their information systems and implement strong security measures to address those risks and vulnerabilities.

Experts repeatedly have expressed concern regarding the state of cybersecurity in the health care industry.^[116] For example, in a 2017 report to Congress, experts convened by the Department pronounced, “Now more than ever, all health care delivery organizations [. . .] have a greater responsibility to secure their systems, medical devices, and patient data.” ^[117] This responsibility has only increased as the delivery of health care and the exchange of PHI have increasingly shifted to cyberspace.

Despite advancements in technology, including health IT, the core requirements of the Security Rule remain relevant and applicable today. In fact, they serve as a foundation for more recently promulgated cybersecurity guidelines, best practices, processes, and procedures. Security management, regular monitoring and review of information system activity, information access management, security awareness and training, contingency planning, encryption, and authentication all continue to be represented in the most well-known cybersecurity frameworks, including the NIST's Cybersecurity Framework,^[118] the HHS 405(d) Program's “Health Industry Cybersecurity Practices: Managing ( print page 907) Threats and Protecting Patients,” ^[119] and the Department's CPGs.^[120]

While these concepts remain highly relevant and applicable, the Department has concerns regarding the sufficiency of the security measures implemented by regulated entities. OCR's experience investigating allegations of Security Rule violations, reports received by OCR of breaches of unsecured PHI, and the results of the audits conducted by OCR in 2016-2017 demonstrate that regulated entities are not consistently complying with the Security Rule's requirements.^[121] Additionally, the Department is concerned about the extent to which regulated entities have updated their security measures to adjust to the changes in the health care environment and their operations, including new and emerging threats to the confidentiality, integrity, and availability of ePHI.

And the Department is not alone in its concerns. NCVHS serves as the Department's advisory body for HIPAA.^[122] Given the increase in cybersecurity incidents affecting the health care sector, NCVHS held a series of public hearings on cybersecurity to better understand how to protect ePHI and individuals. In response to those hearings, NCVHS submitted several recommendations to the Department regarding the importance of strengthening the Security Rule.^[123] As discussed above, HIPAA requires the Secretary to rely on NCVHS' recommendations ^[124] with respect to standards promulgated under the statute.

Given the importance of strong security measures, the changed environment and operations for health care, uncertainty expressed by regulated entities regarding their compliance obligations, deficiencies identified by OCR in its investigations of regulated entities, and the recommendations of NCVHS, we believe that it is necessary and appropriate for the Department to propose modifications to clarify and strengthen the Security Rule.

A. Strong Security Standards Are Essential to Protecting the Confidentiality, Integrity, and Availability of ePHI and Ensuring Quality and Efficiency in the Health Care System

A primary purpose of HIPAA's Administrative Simplification provisions ^[125] is to, among other things, “improve [. . .] the efficiency and effectiveness of the health care system, by encouraging the development of a health information system through the establishment of uniform standards and requirements for the electronic transmission of certain health information.” ^[126] As Congress recognized when it enacted HIPAA, protecting the security of ePHI is essential for accomplishing this goal. Members of Congress acknowledged at that time that the provisions of HIPAA would create electronic databases of PHI, enabling the PHI to be transmitted electronically with both the benefits and risks that accompany such electronic transactions.^[127] Congressional statements leading up to HIPAA's enactment demonstrate Congress' recognition of the potential risks of the shift from paper recordkeeping to electronic: “We need to be very careful about how safe and secure that information is from prying eyes. Some of it may be extremely sensitive and could be used in a malicious or discriminatory manner.” ^[128] Accordingly, HIPAA required the establishment of strict security standards for health information.

As discussed above, the Security Rule, as amended by the HITECH Act, specifically requires regulated entities to maintain reasonable and appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI; to protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI and unauthorized uses or disclosures of ePHI; and ensure compliance with the Administrative Simplification provisions by officers and workforce members of regulated entities.^[129]

It is reasonable to anticipate that regulated entities will need to protect ePHI against cyberattacks and unauthorized uses and disclosures of ePHI by their workforce members. Experts estimate the costs to the U.S. from cyberattacks on health care facilities to be significant.^[130] According to one study, health care data breach costs to affected organizations have increased by more than 50 percent since 2020, making health care data breaches more expensive than data breaches in any other sector, at an average cost of almost $10.1 million per breach.^[131] Yet these costs, though sizeable, do not fully take into account the practical implications of poor or ineffective cybersecurity protocols. A failure to implement adequate security measures may lead to: financial loss; reputational harm for affected individuals and affected regulated entities; privacy loss; and safety concerns.^[132] Additionally, breaches of unsecured PHI may lead to identity theft, fraud, stock manipulation, and competitive disadvantage.^[133] According to a study funded by the Institute for Critical Infrastructure Technology, victims of medical identity theft incur on average costs of $13,500 to recover from that theft.^[134] Unlike financial information, much of an individual's PHI is ( print page 908) immutable. For example, an individual's date and location of birth and their health history will not change, even if their address might. In contrast, an individual's passwords, bank account numbers, and other financial information can all be changed. Thus, PHI can continue to be exploited throughout an individual's lifetime, making PHI likely to be far more valuable than an individual's credit card information.^[135]

On the surface, the harms that result from a breach of ePHI or a cyberattack on a regulated entity's electronic information systems, as discussed above, are not significantly different than those that would result from a breach of information in another sector. However, the reality is, as discussed above, that the implications of such harms are far greater in the health care sector because of their potential to adversely affect an individual's health or quality of life, or even to cost an individual their life.^[136] As stated by the Health Care Industry Cybersecurity Task Force in its 2017 report on the state of cybersecurity in health care: “The health care system cannot deliver effective and safe care without deeper digital connectivity. If the health care system is connected, but insecure, this connectivity could betray patient safety, subjecting them to unnecessary risk and forcing them to pay unaffordable personal costs.” ^[137] In the event of a cybersecurity incident, patients' health, including their lives, may be at risk where such incident creates impediments to the provision of health care, such as interference with the operations of a critical medical device, or to the administrative or clinical operations of a regulated entity, such as preventing the scheduling of appointments or viewing of an individual's health history.^[138]

According to a Cybersecurity & Infrastructure Security Agency (CISA) statistical analysis of the effects of a hypothetical cyberattack on a model hospital, a hospital's relative performance will suffer amidst a cyberattack.^[139] The analysis found that the hypothetical cyberattack would lead to hospital strain from inaccessible patient schedules and records, disrupted communication, and delays in processing and communicating test results in time to effectively treat individuals.^[140] While the analysis did not find any deaths directly attributable to the hypothetical attack, it is logical to conclude that deaths—or at least worsened outcomes—are a significant risk where there are disruptions in communications, as well as delays in processing and communicating test results, especially for emergent or acute medical cases. For example, an inability to access an individual's pharmacy records could affect the ability of a pharmacist to identify known interactions between newly prescribed medications and an existing medication list, potentially leading to an individual's injury or death. Other studies have similarly found that cyberattacks can have a substantial effect on access to health care, and potentially mortality.^[141] In fact, a more recent study found that cyberattacks had disproportionately negative effects on in-hospital mortality rates for Black patients who were already admitted to the hospital at the time of the cyberattack.^[142] A recent survey found that 92 percent of surveyed health care organizations had experienced a cyberattack in the past year ^[143] and almost three-quarters of the respondents who had experienced a cyberattack reported negative effects on patient care, including delays in tests or procedures, longer stays, and increased mortality rates complications from medical procedures, and patient transfers or diversions to other facilities.^[144] A recent letter from NCVHS referenced anecdotal accounts of patient deaths that have been attributed to ransomware attacks.^[145] For example, in 2019, a ransomware attack may have contributed to a baby's death at an Alabama hospital. A change in the baby's fetal heart rate went unnoticed because the large digital display that normally would have displayed the information was affected by the attack. The baby, born with her umbilical cord wrapped around her neck, suffered severe brain damage and died nine months later.^[146]

Cyberattacks can divert both human and machine resources, leading to process slowdowns, cancelled procedures, delayed hospital or unit lockdowns and transfers, increases in wait times for individuals, both increases and decreases in staff utilization, and a decrease in a health care provider's capacity.^[147] A 2020 cyberattack on a large integrated academic health system, attributed to malicious software embedded in an email attachment opened by an employee on their laptop, affected more than 5,000 end-user devices across 1,300 servers and led to revenue losses of more than $63 million.^[148] Though the health care provider's EHR was not infected, it elected to shut the EHR down proactively. Ultimately, the covered entity “experienced 39 days of downtime in outpatient imaging.” ^[149]

In another example, a ransomware attack on an academic level 1 trauma center caused it to go without access to its EHR for 25 days,^[150] and the attack affected 5,000 computers and destroyed the trauma center's electronic information systems that contained ePHI. The hospital lost access to its EHR, internet, and intranet, which also “removed functionality of hospital phones, [EHR] integrated office and surgical scheduling, access to digitized radiology studies, and network account access through local and remote computers.” ^[151]

These serious incidents and resulting effects demonstrate the importance of planning and preparing for a potential ( print page 909) cyberattack or other event that adversely affects a regulated entity's information systems. While such planning and preparation may not prevent all cyberattacks, it can reduce the number of successful incidents and mitigate their effects. In fact, studies have suggested that such preparation may allow for at least close to real-time recovery.^[152]

The effects of a cyberattack are not limited to the regulated entity that experiences it and the individuals whose ePHI is compromised. Surveys conducted by various organizations representing health care providers indicate that an overwhelming majority of health care providers in the U.S. were affected by a ransomware attack on a large health care clearinghouse.^[153] A study published in 2023 examined the effects on the of a cyberattack at a neighboring, unaffiliated hospital on a large academic medical center.^[154] The study found that the academic medical center experienced, among other things, significant increases in the number of patients admitted, ambulance arrivals, waiting room times, and patients leaving without being seen. The study's authors concluded that their findings suggested “that health care cyberattacks such as ransomware are associated with greater disruptions to regional hospitals and should be treated as disasters, necessitating coordinated planning and response efforts.” ^[155] Thus, implementing reasonable and appropriate security measures better protects not only the regulated entity and its ePHI, but other regulated entities with whom it interacts, and may reduce the effects of cyberattacks and other security incidents that adversely affect the confidentiality, integrity, or availability of ePHI.

As discussed above, several industry organizations have published and maintained compilations of voluntary standards, guidelines, best practices, methodologies, procedures, and processes for protecting the security of sensitive and confidential information, including PHI. Additionally, certain Federal health programs now either require or recommend the adoption of specific criteria that are intended to protect the confidentiality, integrity, and availability of ePHI. For example, the Health IT Certification Program maintained by the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) ^[156] sets minimum requirements for certified health IT, including criteria that pertain to cybersecurity.^[157] These criteria are included in the Health IT Certification Program's Health IT Privacy and Security Framework,^[158] which identifies when technical capabilities to support the privacy and security of electronic health information ^[159] must be included in certified health IT products. Additionally, health care providers that participate in certain Federal health programs must use health IT certified to these requirements.^[160] Regulated entities also may want to consider adoption of certified health IT because it could contribute to compliance with the Security Rule. We will continue to work across the Department to ensure the adoption of consistent requirements for Federal programs that support the secure electronic exchange of health information to the extent that such consistency is appropriate. Throughout this preamble, we provide examples of how a regulated entity's participation in other Federal programs that require the use of health IT certified through the ONC Health IT Certification Program, or adoption of other Federal recommendations, such as the HHS CPGs, might support their compliance with the proposals in this NPRM.

Additionally, as discussed above, several organizations have published and maintained compilations of voluntary standards, guidelines, best practices, methodologies, procedures, and processes for protecting the security of sensitive and confidential information, including PHI. These compilations and the State regulations discussed above range from granular ^[161] to high-level ^[162] and from health care-specific ^[163] to industry agnostic.^[164] Despite these differences, these compilations and regulations have a great deal in common with each other—and with the Security Rule, its longevity notwithstanding. In fact, the foundational elements of the Security Rule, promulgated more than 20 years ago, can still be found in cybersecurity compilations published today. They generally either require or recommend administrative, physical, and technical safeguards to identify and mitigate risks and vulnerabilities, implement authentication and access controls, conduct security awareness and training for information system users, and plan for contingencies and incident response.^[165] Additionally, these compilations all require or recommend the designation of a specific individual who is accountable for implementing the requirements or recommendations. And, importantly, they all ultimately address how to maintain the ( print page 910) confidentiality, integrity, and availability of sensitive and confidential information, including ePHI.

A major distinguishing factor between the content of the Security Rule and these compilations and regulations is the Security Rule's scope. The compilations and regulations are designed to protect various types of data and information systems broadly. In comparison, a defining quality of the Security Rule's requirements is that they focus specifically on the protection of ePHI and the information systems that create, receive, maintain, or transmit ePHI. Thus, while the foundational elements of various cybersecurity compilations and State regulations and the Security Rule may be the same, the Security Rule alone addresses the application of those elements to ePHI and all of the components of information systems that create, receive, maintain, or transmit ePHI. Thus, while the standards of the Security Rule generally align with those of other cybersecurity standards, frameworks, best practices, guidelines, processes, and procedures, the specific implementation specifications of the Security Rule reflect the particular sensitivities of the health care industry, particularly small and rural health care providers, in a way that is necessary to ultimately improve the efficiency and effectiveness of the health care system and avoid imposing unreasonable compliance burdens on regulated entities.

B. The Health Care Environment Has Changed Since the Security Rule Was Last Revised and Will Continue To Evolve

The health care sector has undergone a dramatic transformation over the last 24 years, and particularly in the past 10 years, spurred at least in part by the Department's implementation of HIPAA, the HITECH Act, and the Cures Act. The industry has shifted from one that generally relied upon a system of paper-based recordkeeping and siloed devices to one that depends on interconnected information systems to maintain and exchange patient records, conduct research, run health care provider facility management systems, and provide patient care.^[166] This shift is largely the result of HIPAA's emphasis on the development and use of standards and the EHR incentive funds made available under the HITECH Act for health care providers.^[167] Data from ASTP/ONC offer clear and convincing evidence of this shift. In 2008, before the enactment of the HITECH Act, less than 10 percent of non-Federal acute hospitals had implemented what was referred to at the time as a “Basic EHR” ( i.e., an electronic health record).^[168] By 2015, six years after the enactment of the HITECH Act, almost 84 percent had adopted a Basic EHR while 96 percent had adopted a certified EHR.^[169] The transformation was further enabled by the Cures Act, which encouraged the development of a trusted exchange framework for the nationwide exchange of health information and provided penalties for health care providers, health information exchanges and networks, and developers of certified health IT that engage in information blocking.^[170] In 2014, 41 percent of such hospitals routinely had electronic access to clinical information from outside providers or sources when treating a patient.^[171] By 2023, 70 percent of non-Federal acute care hospitals engaged in all domains of interoperable exchange routinely or sometimes, a significant leap forward.^[172] In 2017, only 38 percent of hospitals enabled patients to access their health information using an application and in 2018, 57 percent enabled patient access to their clinical notes in their patient portal; by 2021, 70 percent of hospitals enabled patients to access their health information using an application and 82 percent enabled patients to view their clinical notes in their patient portal.^[173] And just a year later, the percentage of hospitals that supported patient access through applications increased to 86 percent.^[174] Based on this data, it is clear that HIPAA, coupled with the HITECH Act and the Cures Act, has successfully encouraged the development of a nationwide electronic health information system.

Not only is PHI increasingly maintained and transmitted electronically, but treatment is also increasingly provided electronically. The coronavirus disease 2019 (COVID-19) pandemic led to a dramatic increase in the use of telemedicine.^[175] According ( print page 911) to ONC data, only 15 percent of office-based physicians used any form of telemedicine in 2018-19. In 2021, telemedicine usage increased to 87 percent.^[176] The electronic content generated or transmitted during a telemedicine visit constitutes ePHI, so the increase in telemedicine further increases the amount of PHI that is also ePHI.

It is not only the ePHI maintained in EHRs and other electronic recordkeeping systems that faces security risks. Medical equipment and devices are increasingly connected through one or more networks, which means that any issues affecting the network likely will affect the medical equipment and devices.^[177] And some medical equipment and devices rely on off-the-shelf operating systems, such as Windows, Linux, and similar third-party software; ^[178] thus, the medical equipment and devices can experience the same vulnerabilities as personal computing devices. Generally, the U.S. Food & Drug Administration (FDA) does not need to review software patches or configuration updates for off-the-shelf software before a device manufacturer puts them in place because the FDA views most patches and configuration updates as design changes that can be made without prior discussion.^[179]

Cybercriminals may use—or target—technology assets, such as software or medical devices used for treating individuals. For example, in 2021, a cyberattack on cloud-based systems supplied by a particular company compromised the ePHI of more than 200,000 individuals and affected the software for linear accelerators used in radiotherapy, leading to disruptions to cancer treatment.^[180] Thus, to protect technology assets used for treatment, the information systems that create, receive, maintain, and transmit ePHI also must be protected. As another example, in 2013, the Mayo Clinic ^[181] hired a group of ethical hackers ^[182] to identify vulnerabilities in 40 different medical devices.^[183] The hackers were able to gain access to all of the devices, meaning that the devices could all be vulnerable to a cyberattack.^[184] Such attacks may create an opening for a subsequent attack on the device itself or on the regulated entity's information systems that create, receive, maintain, or transmit ePHI, compromising those information systems and the ePHI itself.^[185] It also may lead, intentionally or not, to a loss of device integrity, which could result in the corruption of the device's functionality or the ePHI on the device.^[186] A cyberattack on a medical device may also reduce the ability of the authorized person to use the device ( e.g., a denial of service attack, which is a type of cyberattack that overloads the device by flooding the network with traffic).^[187] Depending on the device and its use, the result of cyberattacks on a medical device could range from little or no effect to serious injury or death.^[188]

According to researchers at Brown University, medical devices are a prime target for cybercriminals. In fact, they believe, “More than just technically feasible, the widespread takedown of medical devices is an imminent threat.” ^[189] A 2023 Government Accountability Office report on medical device cybersecurity described the importance of “robust cybersecurity controls to ensure medical device safety and effectiveness” because of “the increasing integration of wireless, internet- and network-connected capabilities, and the electronic exchange of health information.” ^[190] The FDA has also acknowledged, “As electronic medical devices become increasingly connected to each other and to other technologies, the ability of connected systems to safely, securely and effectively exchange and use the information becomes critical. [. . .] Cybersecurity concerns rise along with the increasing medical device interoperability.” ^[191] Accordingly, in 2023, the FDA issued updated guidance for industry and FDA staff on requirements for cybersecurity in medical devices.^[192]

And then there are digital health applications. When an application is deployed by a covered entity, an application developer may be a business associate and subject to the Security Rule. An application developer may also meet the HIPAA Rules' definition of “health care provider” ^[193] and be a covered entity.^[194] But also, individuals are increasingly interested in accessing their ePHI using applications and transmitting information collected by health and wellness applications to ( print page 912) their health care providers.^[195] Such applications may empower individuals to better manage their health and participate in their health care and provide health care providers and researchers with a more holistic view of the individual's health at a particular point in time and over an extended period of time.^[196] This technology, while valuable for understanding an individual's overall health, introduces another potential vulnerability to the security of ePHI and the information systems that create, receive, maintain, or transmit it.

EHRs, networked medical devices, and applications are only the beginning. Artificial intelligence (AI) in health care, particularly for diagnosis and treatment, is in the nascent stages of development, but many are eager to test its promise.^[197] After all, many experts believe that AI promises opportunities to improve patient care, outcomes, and population health, as well as to reduce costs.^[198] The use of AI in health care is increasing and is expected to continue to increase.^[199] A 2023 Healthcare Information and Management Systems Society (HIMSS) survey of health care cybersecurity professionals reported that approximately 50 percent of respondents' organizations permitted the use of generative AI technology.^[200] And other new technologies are expected shortly, as discussed below. For example, according to reports, quantum computing may be available in the near future, which may have ramifications for data privacy and security.^[201] We also know that researchers are exploring methods for storing ePHI in biological material ( e.g., DNA).^[202]

While the promise of these new technologies is exciting, they come with increased risks and vulnerabilities to ePHI and the information systems that create, receive, maintain, or transmit it. As noted by Executive Order (E.O.) 14110, “[AI] must be safe and secure. Meeting this goal requires [. . .] addressing AI systems' most pressing security risks—including with respect to biotechnology, cybersecurity, critical infrastructure, and other national security dangers—while navigating AI's opacity and complexity.” ^[203] For these reasons, the E.O. required the Secretary of HHS, in consultation with the Secretary of Defense and the Secretary of Veterans Affairs, to establish an HHS AI Task Force to develop a strategic plan that includes policies and frameworks on responsible deployment and use of AI and AI-enabled technologies in the health and human services sector, including the incorporation of safety, privacy, and security standards into the software-development lifecycle for the protection of personally identifiable information, such as measures to address AI-enhanced cybersecurity threats in the health and human services sector.^[204] The Department has taken a number of actions to address the use of AI in health care, including establishing an AI Council, appointing a Chief AI Officer,^[205] and taking steps to regulate the use of AI in health care.^[206] Accordingly, regulated entities must be prepared to identify, mitigate, and remediate such risks and vulnerabilities.

While the health care industry has generally shifted from paper record-keeping and non-interoperable electronic devices to an interconnected electronic health care system, it has led to an increasing vulnerability to breaches of unsecured PHI resulting from unauthorized uses and disclosures and cyberattacks. According to an article published by the American Hospital Association Center for Health Innovation, “Health care organizations are particularly vulnerable and targeted by cyberattacks because they possess so much information of high monetary and intelligence value to cyber thieves and nation-state actors.” ^[207] In fact, “[. . .] on the dark web, PHI is deemed more ( print page 913) valuable than credit card data, enabling cybercriminals to extract as much as [$1,000] per stolen medical record.” ^[208] Before this shift to an interconnected electronic system, lost or misplaced paper records or even a laptop could lead to a breach of unsecured PHI affecting hundreds or thousands of individuals.^[209] While a breach of that size remains significant, unauthorized access to a single workstation today could lead to a breach that affects millions of individuals because of the increase in interconnectivity.^[210]

Between 2018 and 2023, the number of breaches of unsecured PHI reported to the Department grew at an alarming rate (100 percent increase), as did the number of individuals affected by such breaches (950 percent increase).^[211] The reports reflect rampant escalation of cyberattacks using hacking (260 percent increase) and ransomware (264 percent increase).^[212] Based on reports made to OCR, in 2022, approximately three-fourths of the breaches of unsecured PHI affecting 500 or more individuals were the result of hacking of electronic equipment or a network server.^[213] In 2023, over 160 million individuals were affected by breaches involving the PHI of 500 or more individuals—a new record. We anticipate that 2024 will surpass that record, particularly in light of the estimate provided by a large covered entity regarding the number of individuals affected by a breach of its subsidiary.^[214]

In 2023, the Federal Bureau of Investigation's internet Crime Complaint Center received almost 250 reports of ransomware affecting the Healthcare and Public Health sector, the most of any of the 16 identified infrastructure sectors.^[215] The Healthcare and Public Health sector has been the most targeted critical infrastructure sector since at least as far back as 2015.^[216] Between 2015 and 2019, cyberattacks on health care organizations increased by 125 percent.^[217] And between 2022 and 2023, ransomware attacks against the U.S. health care sector increased 128 percent.^[218]

Many people, including regulated entities, inaccurately believe that only large regulated entities that maintain electronic records about millions of individuals are likely to face a cyberattack, and thus that it is less important for smaller regulated entities to invest resources in cybersecurity.^[219] In fact, smaller regulated entities may also be the target of, or adversely affected by, cybercrime, partly because of the interconnectedness of health care and partly because they are less likely to have invested in cybersecurity, making them easier targets.^[220]

As explained in a recent national security memorandum, cybercriminals are targeting critical infrastructure ( i.e., the physical and virtual assets and systems so vital to the Nation that their incapacity or destruction would have a debilitating impact on national security, national economic security, or national public health or safety), and their activities may be tolerated or enabled by other countries.^[221] Thus, it is essential that the Department and regulated entities take steps to safeguard health care infrastructure and ePHI.

External actors are not the only, or even the greatest, threat to the security of ePHI. According to a recent study, insiders were the second leading cause of breaches in the health care sector in 2023, exceeded only by “miscellaneous errors,” such as misdelivery.^[222] For example, a recent settlement resolved an OCR investigation involving the theft and sale of the ePHI of more than 12,000 patients by an employee of a large health care system.^[223] In another example, security guards at a large health care provider were alleged to have used their login credentials to inappropriately access ePHI.^[224] Thus, it is critical that regulated entities improve their cybersecurity posture to protect not only against external threats but also ( print page 914) internal ones, and both intentional and accidental breaches.

Emergencies or other occurrences can affect the security of ePHI without an intentional act. For example, in 2024, CrowdStrike released a defective update for its software on computers running Microsoft Windows.^[225] This update affected the ability of regulated entities to access the ePHI of millions of individuals for varying periods of time. During this time, ePHI was unavailable, meaning that one of the key prongs of the security triad of confidentiality, integrity, and availability was affected.^[226] Because of the increased digitization of PHI, it is, for example, essential that covered health care providers engage in thoughtful contingency planning that considers how they will proceed in the event that they are unable to access ePHI in their EHRs. Additionally, threat actors will often seek to take advantage of such incidents. As reported by a large subcontractor of a business associate, less than a week after the outage, the company “observed threat actors leveraging the event to distribute” ransomware.^[227] The environment in which health care is delivered, the way in which it is delivered, and the manner in which related information is collected all mean that regulated entities must consider a different approach to operational continuity and resiliency in the face of such challenges. Additionally, they must be wary of the potential for bad actors to attempt to take advantage of such events.

C. Regulated Entities' Compliance With the Requirements of the Security Rule Is Inconsistent

Despite the proliferation of cybersecurity standards, guidelines, best practices, methodologies, procedures, and processes and the documented increase in unauthorized uses and disclosures of ePHI, many regulated entities have been slow to strengthen their security measures to protect ePHI and their information systems that create, receive, maintain, or transmit it in this new environment.^[228] Among the reasons for this are the rapid pace of EHR adoption and digitization of health care, increased connectivity and use of cloud-based infrastructures, limited competition and a stable customer base, limited operating margins, and a failure to invest in cybersecurity infrastructure.^[229] For example, regulated entities continue to rely on legacy systems and software that are unsupported by manufacturers, which means that the manufacturers no longer provide security patches or other updates to address security threats and vulnerabilities.^[230] In a 2021 survey of health care cybersecurity professionals, 73 percent reported having legacy operating systems.^[231] This apparent lack of urgency in adopting new, supported operating systems has serious implications for the confidentiality, integrity, and availability of ePHI.

In addition, many regulated entities fail to invest adequate resources in cybersecurity. Far too many regulated entities do not view cybersecurity as a necessary component of their operations that allows them to fulfill their health care missions. Anecdotal evidence suggests that senior management often lacks awareness of cybersecurity, including both threats and methods for protecting against such threats.^[232] “A lack of maturity and effectiveness of the [information technology] function is evident when healthcare organizations fail to maintain a current inventory of sensitive and valuable data and where those reside.” ^[233] While maintaining an accurate and thorough inventory of technology assets is not currently an explicit requirement of the Security Rule, it is clearly a fundamental component of conducting a risk analysis and many of the other existing requirements.^[234] And yet, based on the Department's experience, many regulated entities are not maintaining such an inventory. At least in part because of senior management's lack of cybersecurity awareness, many fail to invest or fail to invest appropriately in cybersecurity infrastructure.^[235] Given the vulnerability of ePHI and the information systems of regulated entities and the potential effects of cyberattacks on patient safety and the delivery of health care, it is important that regulated entities prioritize such investments.^[236]

The security of ePHI also is at risk because, despite our explanation of the Security Rule's structure in 2003,^[237] regulated entities are not fully complying with the standards and implementation specifications. From 2016 to 2017, the Department conducted audits of 166 covered entities and 41 business associates regarding compliance with selected provisions of the HIPAA Rules, including the required implementation specifications for risk analysis ^[238] and risk management.^[239] The Department found that most regulated entities failed to implement the Security Rule requirements for risk analysis and risk management, requirements that are fundamental to protecting the confidentiality, integrity, and availability of ePHI.^[240] While most of the audited business associates reported not having experienced any breaches of unsecured PHI, we found that those that ( print page 915) had experienced a breach generally engaged in minimal or negligible efforts to address the risk analysis and risk management requirements.^[241] According to the report, at that time only 14 percent of covered entities and 17 percent of business associates were “substantially fulfilling their regulatory responsibilities to safeguard ePHI they [held] through risk analysis activities,” ^[242] while 94 percent of covered entities and 88 percent of business associates “failed to implement appropriate risk management activities sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” ^[243] The report specifically noted that the audit results were consistent with the findings of OCR's compliance reviews and complaint investigations.^[244]

Recent enforcement actions provide evidence that the results of the 2016-2017 audits were not isolated cases. In 2023, OCR entered into seven resolution agreements with regulated entities after investigations indicated that they had potentially violated the Security Rule, constituting almost half of the total resolution agreements OCR entered into that year.^[245] In each case, OCR's investigation found evidence of multiple potential violations. For example, in one case, a regulated entity did not detect an intrusion into its network until 20 months later when its files were encrypted with ransomware.^[246] OCR's investigation found evidence of potential failures of the regulated entity to conduct a risk analysis or to sufficiently monitor information system activity. OCR also found evidence that the regulated entity may not have had policies and procedures in place to implement the requirements of the Security Rule to protect the confidentiality, integrity, and availability of ePHI.^[247]

As another example, an OCR investigation of a large health care system found indications of multiple potential violations of the Security Rule, including failures by the regulated entity to conduct a risk analysis, monitor and safeguard its electronic information systems, and implement policies and procedures to record and examine activity in its electronic information systems containing ePHI.^[248] The regulated entity was not only unable to prevent the cyberattack, but it was unaware the attack had occurred until two years later. This is despite the long-standing requirements of the Security Rule and the obligations imposed on regulated entities for risk analysis and risk management.

Despite the long-standing nature of the Security Rule and the proliferation of guidance documents from NIST, the Department, CISA, FTC, and others, regulated entities continue to fail to implement reasonable and appropriate security measures as required by the Security Rule.^[249] For example, the Security Rule and NIST guidance have addressed encryption for data in transit and at rest for many years.^[250] And yet, in the 2021 survey of health care cybersecurity professionals, only half of the respondents reported having implemented encryption for data in transit across the enterprise.^[251] Similarly, according to its CEO, a large covered entity failed to deploy multi-factor authentication (MFA) throughout its enterprise and experienced a significant breach.^[252] If this is accurate, it would run counter to long-standing provisions in both the Security Rule and NIST guidance; the Security Rule has required the implementation of appropriate access controls since 2003 and NIST recommends similar controls.^[253]

As another example, based on OCR's investigation experience, some regulated entities are not developing and implementing compliant response plans for security incidents, including those that are breaches of unsecured ePHI under the Breach Notification Rule. Section 164.308(a)(6)(i) establishes the standard that requires regulated entities to implement policies and procedures to address security incidents, while 45 CFR 164.308(a)(6)(ii) includes the implementation specifications for that standard. This requirement, included in the 2003 Final Rule, aligns with the NIST Cybersecurity Framework version 2.0 requirement for incident management.^[254] Similarly, NIST Cybersecurity Framework version 1.1 recommended the execution and maintenance of response processes and procedures to ensure response to detected cybersecurity incidents.^[255] And yet, when OCR investigates the circumstances surrounding breach reports, OCR continues to find evidence that regulated entities have not implemented policies and procedures to detect and respond to security incidents, leading to significant time lapses between a “successful” security incident ^[256] and discovery of, and response to, the security incident.^[257] Thus, based on the OCR's experience investigating and enforcing the Security Rule, the Department believes that many regulated entities would benefit from additional instruction in regulatory text regarding their compliance obligations to determine how to select security ( print page 916) measures that are reasonable and appropriate for their circumstances.

We are also concerned that recent caselaw has not accurately set forth the steps regulated entities must take to adequately protect the confidentiality, integrity, and availability of ePHI, as required by the statute. Specifically, in the University of Texas M.D. Anderson Cancer Center v. HHS (“ M.D. Anderson ”), the U.S. Court of Appeals for the Fifth Circuit held, among other things, that the Security Rule does not say anything about how effective a mechanism for encryption must be, nor does it require that an encryption mechanism provide “bulletproof protection” of all systems containing ePHI.^[258] Thus, under the court's interpretation, a regulated entity can meet its obligations under the Security Rule concerning encryption and decryption of ePHI by implementing a mechanism to do so, without regard for the effectiveness of the implementation.^[259] Additionally, the court noted that the requirement for “a mechanism” does not “prohibit a [regulated] entity from creating `a mechanism' by directing employees to sign an [agreement] that requires the encryption of portable devices.” ^[260] While the Department disagrees with the court's interpretation that merely requiring employees to sign an agreement to encrypt portable devices is sufficient to comply with its Security Rule obligations to implement a mechanism to encrypt and decrypt ePHI, the Department believes that additional clarity is warranted to ensure that regulated entities understand their obligation to have encryption mechanisms in place and deployed throughout the regulated entity's enterprise to ensure the confidentiality, integrity, and availability of ePHI.

Several technical safeguards currently require regulated entities to implement a “mechanism” as part of complying with the associated standard. Given that written policies and procedures alone are insufficient to protect ePHI, and the misinterpretation of what it means to implement a mechanism also could lead to inadequate protection of ePHI, the Department believes that the Security Rule must be revised, consistent with its statutory mandate, as discussed in greater detail above.

D. It Is Reasonable and Appropriate To Strengthen the Security Rule To Address the Changes in the Health Care Environment and Clarify the Compliance Obligations of Regulated Entities

1. Congress and the Department Anticipated That Security Standards Safeguards Would Evolve To Address Changes in the Health Care Environment

By requiring that regulated entities maintain reasonable and appropriate safeguards to protect against reasonably anticipated threats or hazards or unauthorized uses or disclosures of ePHI, Congress clearly anticipated that the administrative, physical, and technical safeguards implemented to protect the security of ePHI would need to change in response to changes in the environment in which health care is provided.^[261] As the health care environment and the operations of regulated entities evolve, so must the protections for ePHI and the information systems used to create, receive, maintain, or transmit it. For example, regulated entities must be expected to adopt safeguards that address new risks to the security of ePHI, such as those posed by maintaining ePHI in the cloud; the connection of medical devices and other technology to networks; and the connection of information systems used to create, receive, maintain, or transmit ePHI to the same networks as those do not perform such activities. After all, it is reasonable to anticipate that there will be new threats or hazards to ePHI or efforts by unauthorized persons to use or disclose such ePHI in an increasingly connected environment.

By design, the Security Rule sets a national floor for the security measures that regulated entities are required to implement to protect the confidentiality, integrity, and availability of ePHI. In 2003, the Department opted to frame the standards in terms that were as generic as possible and in a manner that enabled the standards to be met through various approaches or technologies to ensure that regulated entities had the flexibility to determine how best to protect the confidentiality, integrity, and availability of ePHI based on their specific circumstances.^[262] When we extended the Security Rule in 2013 to directly apply to business associates in accordance with the HITECH Act,^[263] the Department acknowledged that some business associates might not have engaged in the formal administrative safeguards required by the Security Rule, and we made it clear that business associates would be expected to do so going forward.^[264] Despite the changes in the health care environment between 2003 and 2013, the Department made minimal changes to the Security Rule at that time because we believed that the compliance obligations of regulated entities were clear and well-understood. In fact, when a commenter recommended that the Department remove the “addressable” designation from the Security Rule because it leads to ambiguity in the rule's application, we declined to do so at that time because we were concerned that it would reduce the rule's scalability and flexibility.^[265] However, as we noted in 2003, the rule's flexibility of approach is primarily provided for in paragraph (b)(2) of 45 CFR 164.306 and in the standards themselves.^[266] The addressability feature merely provided an added level of flexibility ^[267] in a way that the Department now believes is inadequate to ensure that regulated entities implement reasonable and appropriate security safeguards.

Changes to the health care environment and the operations of regulated entities have increased the importance of implementing strong security measures to protect ePHI and the information systems that create, receive, maintain, or transmit it. While we recognize the burdens posed by such implementation on regulated entities, there is also a clearly documented increase in the number of breaches of unsecured PHI and instances of cybercriminals accessing ePHI without authorization at regulated entities. The changes to the health care environment, including the increase in breaches and cyberattacks, and operations of regulated entities have made it increasingly likely that unauthorized persons will seek to obtain ePHI and disrupt the U.S. health care system. Additionally, the clearly documented failure of regulated entities to fully implement the policies and procedures required by the Security Rule and apply the required security measures throughout their operations has caused the Department to question whether the existing Security Rule should be revised to clarify and strengthen the obligations of regulated entities and revisit our ( print page 917) decision from 2013.^[268] In many cases involving a breach of ePHI that OCR has investigated, a breach may not have occurred, or would have been less widespread and disruptive, had the regulated entities fully implemented the provisions of the Security Rule.^[269]

2. NCVHS Believes That the Security Standards Evolve To Address Changes in the Health Care Environment

The Department is not alone in believing that the Security Rule should be strengthened to address concerns about whether -regulated entities are sufficiently protecting the confidentiality, integrity, and availability of ePHI. An inquiry conducted by NCVHS between July 2021 and September 2023 reached the same conclusion.^[270] During this inquiry, NCVHS listened to the testimony of cybersecurity experts and Department officials. The experts and Department officials “consistently voiced their concerns about the major increase in incidents and, in particular, the widespread lack of robust risk analysis on the part of covered entities and business associates that would lead to prior planning for, and mitigation of, a range of cybersecurity threats.” ^[271] In response to this inquiry and consistent with their statutory mandate,^[272] NCVHS transmitted two letters to the Secretary with recommendations for improving cybersecurity practices in the health care industry, including recommendations for modifying the Security Rule.^[273] As part of the explanation for its concerns, NCVHS cited a 2021 survey of acute and ambulatory care organizations that found only 32 percent of those organizations had a comprehensive security program, while only 26 percent of the long-term and post-acute care facilities met the minimum security requirements.^[274] Specifically, NCVHS made the following recommendations for improvements to the Security Rule:

• Eliminate from the addressable implementation specifications the choice not to implement a specification or alternative, and instead require regulated entities to implement the specification or adopt a documented reasonable alternative.^[275]

• Include specific minimum cybersecurity hygiene requirements that are reflective of modern industry best practices, including designation of a qualified information security official, elimination of default passwords, adoption of MFA, institution of offline backups, installation of critical patches within a reasonable time, and transparency of impact and vulnerability disclosures.^[276]

• Require that regulated entities implement a security program and that they implement standard minimum security controls.^[277]

• Require that regulated entities adopt a risk-based approach in their security program.^[278]

• Require that regulated entities perform a risk analysis in a manner that conforms with guidance from NIST and CISA.^[279]

• Define compensating controls more specifically and provide a wider range of examples that apply to a greater variety of types of entities.^[280]

• Reinforce the need for regulated entities to account for AI systems and data within their risk analysis for all and any new technology.^[281]

• Establish a consistent floor for cyber incident reporting and harmonize such requirements with incident reporting provisions applicable to health care critical infrastructure actors and health care Federal contractors.^[282]

The Department, in drafting this NPRM, relied on the recommendations of NCVHS, OCR's enforcement experience, news reports, and our assessment of the environment. Consistent with NCVHS' recommendation to revisit the Security Rule's classification of some implementation specifications as “addressable,” the Department also believes that it is appropriate to revisit our decision regarding the amount of flexibility regulated entities have in determining reasonable and appropriate safeguards, as described above. Based on OCR's experience in investigations and audits, we believe that regulated entities would benefit from greater specificity in the Security Rule. The Department has provided extensive guidance on questions to consider when adopting and implementing security measures and ways to comply with the Security Rule,^[283] as directed by the HITECH Act. And yet, despite this proliferation of guidance, regulated entities continue not to comply. For example, despite the explanation in 45 CFR 164.306(d) about addressable implementation specifications and the notable changes in the environment in which health care is provided, we are concerned that some regulated entities proceed as if compliance with an addressable implementation specification is optional—and that where there is an addressable implementation specification, that compliance with the relevant standard is also optional. That interpretation is incorrect and weakens the cybersecurity posture of regulated entities. We believe that compliance with the implementation specifications currently designated as addressable is not—and should not be—optional, particularly in light of the shift to an interconnected and cloud-based environment and a significant increase in the number of breaches of unsecured PHI from both internal and external actors, regardless of the regulated entity's specific circumstances. Thus, we believe that it is necessary to strengthen the Security Rule to reflect the changes in the health care environment and the evolution of ( print page 918) technology and to underscore that compliance with all of our proposals, if finalized, is required.

3. A Strengthened Security Rule Would Continue To Be Flexible and Scalable While Providing Regulated Entities With Greater Clarity

The Security Rule's fundamental flexibility and scalability generally would remain should the proposals in this NPRM be adopted. However, we are proposing to reduce that flexibility to better strengthen protections and address the changed nature of the environment in which health care is provided. The Department is also proposing in this NPRM to strengthen the Security Rule by providing greater clarity regarding the nature of its flexibility and scalability and the Department's expectations, as requested by regulated entities and other stakeholders. In fact, in response to a request for information published in 2022,^[284] several commenters urged the Department to propose regulations that establish a single set of clear standards for regulated entities, raise the floor for security requirements and expectations, and encourage regulated entities to safeguard ePHI while maintaining flexibility and scalability. Commenters also encouraged the Department to rely on commonly available, non-proprietary frameworks that allow regulated entities to adopt critical security measures. We believe that our proposals are consistent with those recommendations.

Under the proposal, regulated entities would retain the ability to determine the security measures that are reasonable and appropriate to fulfill the required standards and implementation specifications, taking into consideration the factors listed at proposed 45 CFR 164.306(b)(2). In fact, the NPRM, if adopted as proposed, would add to the rule's flexibility and scalability by adding a new factor for regulated entities to consider when determining the reasonable and appropriate security measures.^[285]

Additionally, if modifications are adopted as proposed, the Security Rule would remain flexible and scalable by retaining broad standards with which regulated entities could comply in a variety of ways. In 2003, the 13 implementation specifications that the Security Rule requires were considered so basic that no covered entity could effectively protect ePHI without implementing them.^[286] While the Department agrees that these implementation specifications remain essential, we no longer believe that they are sufficient to address the risks to ePHI today. Rather, regulated entities must do more to ensure the confidentiality, integrity, and availability of ePHI today because of the changes in the environment in which health care is provided, how ePHI is maintained, the level of connectivity between information systems, and the technological sophistication of bad actors.

We acknowledged in 2003 and again acknowledge here that “there is no such thing as a totally secure system that carries no risks to security.” ^[287] We posited at that time that Congress intended to set an “exceptionally high goal for the security of [ePHI],” while also recognizing that securing ePHI did not require that covered entities do so without regard for the cost.^[288] However, we also made clear that a covered entity is required to implement adequate security measures and that cost was but one factor for a covered entity to consider when determining what constituted appropriate security measures.^[289] As we noted, “Cost is not meant to free covered entities from this responsibility.” ^[290] In the 2013 Omnibus Rule, we further explained that “[regulated entities] have the flexibility to choose security measures appropriate for their size, resources, and the nature of the security risks they face, enabling them to reasonably implement any given Security Rule standard. [. . .] Thus, the costs of implementing for [. . .] business associates will be proportional to their size and resources.” ^[291] We continue to believe that this is the case. Additionally, as discussed above, there is a significant cost associated with breaches and unauthorized access—financial, reputational (for both the individual and the regulated entity), and more. Thus, we believe that the standards and implementation specifications that we propose in this NPRM are the minimum that regulated entities should be doing to protect the security of ePHI and lower the costs associated with breaches and other incidents.

4. Small and Rural Health Care Providers Must Implement Strong Security Measures To Provide Efficient and Effective Health Care

The statute requires that we consider the “needs and capabilities of small health care providers and rural health care providers (as such providers are defined by the Secretary).” ^[292] We recognize that small and rural health care providers may have needs and capabilities that differ from those of other regulated entities. For example, small health care providers and rural health care providers are often located at a greater distance from other health care providers.^[293] It may be more challenging for them to attract and retain clinicians and administrative support staff.^[294] They also face difficulty attracting and retaining security experts and must make difficult decisions regarding investments in competing priorities.^[295] Often, preparation for security incidents or other occurrences that adversely affect the confidentiality, integrity, or availability of ePHI is neglected in favor of other priorities, putting small and rural health care providers at greater risk for such an occurrence.^[296]

We continue to believe that it is just as important for small and rural health care providers to implement strong security measures as it is for larger health care providers and other categories of regulated entities. According to experts, “Cybercriminals go after small businesses, especially those in the healthcare industry, ( print page 919) because they are easy targets.” ^[297] In 2017, 93 percent of small rural and critical access hospitals and 86 percent of physician offices relied on health IT to inform their clinical practice.^[298] And yet, small health care providers are less likely than a larger organization to even have a designated security or compliance officer.^[299] Smaller practices and rural and community facilities also may be more likely to rely on older technologies that are no longer supported by security patches and updates, including medical devices such as insulin pumps and pacemakers in which inaccuracies or errors could affect patient safety.^[300] Thus, small health care providers “are at the greatest risk of a breach. [. . .] Smaller, rural practice settings are especially high-risk target areas for a breach.” ^[301] According to an expert who speaks to and works with health care providers on IT services and cybersecurity, small health care providers are “more susceptible because they do not have a lot of the tools and security measures necessary to protect themselves.” ^[302] For example, a critical access hospital in Colorado recovered from a cyberattack in 2019, but it required “an incredible amount of staff time, many months of recovery efforts, and an enormous financial outlay to restore systems and prevent another attack.” ^[303] In fact, the hospital estimates that “it took a full year of a staff person's time to complete the recovery and protect the organization for the future.” ^[304] These costs do not include the multiple ransoms paid to the attackers after the first set of keys did not unlock all of the data.^[305]

Patients and communities have a critical need for health care providers, including rural hospitals and other rural health care providers, to be resilient and remain operational, which depends in part on the cybersecurity of their electronic information systems. For rural health care providers, especially hospitals, a breach can significantly affect an entire community.^[306] Rural health care providers often are separated by significant distances, which can have real consequences for someone experiencing a medical emergency.^[307] A recent study comparing hospital characteristics and operations of rural and urban hospitals that experienced ransomware attacks between 2016 and 2021 found that rural hospitals experienced large declines in inpatient admissions and Medicare revenue, similar to those experienced by urban hospitals.^[308] The study also found that the decline in volume and revenue of hospital outpatient and emergency room visits was more pronounced among rural facilities.^[309] In fact, in June 2023, a hospital in rural Illinois announced that it would close, in part because a 2021 cyberattack prevented it from submitting claims to health plans for months.^[310] According to a local elected official, the hospital's closure would require some residents to travel approximately 30 minutes for the nearest emergency room and obstetrics services.^[311] Thus, implementing security measures to maintain facility operations is critical to minimize or avoid disruptions to patient care and patient safety activities in such facilities. Consistent with these examples, the Department believes that small and rural health care providers are also viewed as potential targets by cybercriminals, and such providers need to implement strong cybersecurity measures to secure the ePHI in their possession. In fact, in June 2024, the Administration announced a collaboration with the private sector to provide additional cybersecurity resources for rural health care providers in recognition of the importance of protecting the security of ePHI created, received, maintained, or transmitted by such entities.^[312] We believe this collaboration will provide small and rural health care providers with additional support, particularly when coupled with other resources described in greater detail below.^[313] Thus, we believe that small and rural health care providers have both the need to comply with the proposals in this NPRM and the capability of doing so. Additionally, we believe that the NPRM would continue to provide all regulated entities, including small and rural health care providers, the ability to take into account their circumstances when determining which security measures are reasonable and appropriate.^[314]

5. A Strengthened Security Rule Is Critical to an Efficient and Effective Health Care System

While the Security Rule generally continues to accomplish a primary goal of HIPAA,^[315] the Department believes that it is essential to propose modifications to strengthen its protections for the confidentiality, integrity, and availability of ePHI to address the changing health care environment. We also believe it is important to clarify the obligations of regulated entities and emphasize the importance of protecting the confidentiality, integrity, and availability of ePHI. We believe that the proposed revisions would require regulated entities to consider and potentially modify their safeguards more regularly, which would better enable them to quickly respond to changes in the environment and be consistent with cybersecurity best practices. While we do not expect that compliance with the Security Rule will ( print page 920) prevent all breaches or interruptions in the confidentiality, integrity, or availability of ePHI, we believe that it will prevent many and enable regulated entities to identify, mitigate, and remediate the damage more quickly if there is a breach or other security incident, thereby reducing harm to individuals and the overall costs of such occurrences to regulated entities and to the U.S. health care system. As such, the proposed modifications would support a primary goal of HIPAA's Administrative Simplification provisions: improving the efficiency and effectiveness of the U.S. health care system by encouraging the development of health information systems through the establishment of uniform standards and requirements for electronic transmission of ePHI, including those for security.^[316]

E. The Secretary Must Develop Standards for the Security of ePHI Because None Have Been Developed by an ANSI-Accredited Standard Setting Organization

HIPAA requires the Secretary to adopt standards that have been developed, adopted, or modified by a standard setting organization accredited by ANSI, except in certain circumstances.^[317] For example, HIPAA permits the Secretary to develop standards where no relevant standards have been developed, adopted, or modified by an ANSI-accredited standard setting organization. In developing, adopting, or modifying a standard, the Secretary is required to consult with standard setting organizations, NCVHS, and with the appropriate Federal and State agencies.^[318]

The statutory definition of the term “standard” applies only to standards for electronic transactions and data elements for such transactions that are appropriate for: (1) the financial and administrative transactions described in the statute; and (2) other financial and administrative transactions consistent with the goals of improving the operation of the health care system and reducing administrative costs, as determined appropriate by the Secretary.^[319] Under HIPAA, security is not considered a financial or administrative transaction, or a data element of such transaction.^[320] In the “Health Insurance Reform: Standards for Electronic Transactions” final rule in 2000, we explicitly adopted a broader definition of “standard” because we recognized that the statutory definition only applied to standards for financial and administrative transactions, despite the statute's requirement that the Secretary adopt standards addressing other matters, including privacy and security.^[321] At that time, we explained that we adopted a broader definition of standard to accommodate the varying functions of the specific standards proposed in other HIPAA regulations.^[322] For the same reason, we believe that it is appropriate to continue to rely on the regulatory definition of standard.^[323]

As discussed above, in both 1998 and 2003, the Department determined that no comprehensive, scalable, and technology-neutral set of standards exists, and accordingly, we proposed and adopted a new standard.^[324] In 2013, we made only minor modifications to the standards when we complied with explicit directions from Congress to apply the requirements of the Security Rule to business associates, so we did not need to consider whether an ANSI-accredited standard setting organization had adopted a comprehensive set of standards on the security for ePHI that was flexible, scalable, and technology-neutral.^[325]

However, because we believe it is appropriate for us to consider modifying the Security Rule at this time for the reasons discussed above, we must again consider whether an ANSI-accredited standards setting organization has developed, adopted, or modified a standard relating to the security of ePHI. The Department continues to believe that any standard must be comprehensive, rather than piecemeal, as recommended by the ANSI Healthcare Informatics Standards Board.^[326] We also continue to agree with the recommendation that the standards should be technology-neutral because security technology continues to evolve to keep pace with the evolution of technology more broadly. Additionally, the Security Rule must remain flexible and scalable to allow for consideration of the wide variety of regulated entities, enabling such entities to determine the reasonable and appropriate security measures for their circumstances by taking into account the factors specified by HIPAA.^[327]

We are not aware of any standard setting organizations that are accredited by ANSI that have issued standards for the security of ePHI, let alone standards that are sufficiently comprehensive, flexible, scalable, and technology-neutral to enable regulated entities to take into account the HIPAA factors. For example, NIST has issued numerous publications addressing health care cybersecurity that are considered by NIST to be guidance, rather than standards. In fact, NIST is ANSI-accredited for only one standard.^[328] And with the exception of publications that analyze the Security Rule, NIST's guidance does not specifically address the security of ePHI. CISA has issued cross-sector CPGs, but it is not ANSI-accredited. There may be other organizations that have set standards for the transmission of particular information, such as the secure transmission of images, but adopting such individual standards would not meet the Department's criteria. In this case, adoption of such standard would be far too granular and require the Department to revise the Security Rule at the same interval as the particular standard, which may be irregular. Additionally, given that the Department is limited to modifying each standard or implementation specification no more frequently than once every 12 months, this approach would be inefficient and could lead to a requirement that the Department update the Security Rule more than once a year, depending on when such individual standards or implementation specifications are revised. Even modifying the standards annually would require a significant investment of Department resources, not to mention the investment required of regulated entities to comply with an ever-changing set of requirements.

Additionally, in 2021, Congress amended the HITECH Act to require the Secretary to consider whether a regulated entity has adequately demonstrated that it had in place recognized security practices for a certain period of time.^[329] Congress defined “recognized security practices” to include certain NIST publications; the approaches promulgated under ( print page 921) section 405(d) of the Cybersecurity Act of 2015; “and other programs and processes that address cybersecurity and that are developed, recognized, or promulgated through regulations under other statutory authorities.” ^[330] However, the HITECH Act amendment did not require the Secretary to accept a regulated entity's implementation of recognized security practices as an alternative to compliance with the Security Rule, nor did it provide that such implementation was sufficient to meet the security objectives of HIPAA or the HITECH Act. Accordingly, it is appropriate for the Department to develop and adopt its own standards to meet the statutory objective of ensuring the security of ePHI. The standards and implementation specifications proposed herein take into consideration not only those promulgated by NIST, but also guidelines, best practices, methodologies, processes, and procedures published by CISA, the HHS 405(d) program, CMS, State governments, and others. The proposals also enable regulated entities to adopt security measures that ensure the confidentiality, integrity, and availability of ePHI; protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI and unauthorized uses or disclosures of such ePHI; ensure compliance with the Security Rule by the workforce members of regulated entities, while also taking into account the technical capabilities of record systems used to maintain ePHI; the costs of such measures; the need for training users who have access to ePHI; the value of audit trails in computerized record systems; and the needs and capabilities of small and rural health care providers.

The Department has consulted with and relied on the recommendations of NCVHS in the formulation of this proposed rule ^[331] and intends to continue to engage in these consultations before finalizing the rule.^[332] We also expect to consult with the National Uniform Billing Committee, the National Uniform Claim Committee, the Workgroup for Electronic Data Interchange, and the American Dental Association before finalizing this rule, as required by section 1172(c)(3)(A)(ii) of HIPAA.^[333]

IV. Section-by-Section Description of the Proposed Amendments to the Security Rule

This section contains a description of the proposed amendments to the Security Rule and the Department's rationale for its proposals. As part of this rationale, we often include a discussion of best practices contained in previously published guidance documents issued by the Department, NIST, and other Federal agencies. We request comment on previously published guidance documents that are not discussed herein that were issued by the Department or other Federal agencies and contain best practices but may be relevant or applicable to regulated entities, including the names of and citations for such guidance documents. We do not propose to adopt referenced best practices as the standard or implementation specifications unless otherwise specified in the proposed regulatory text. Rather, we include such discussion to provide regulated entities with context for the aforementioned proposals. We recognize that regulated entities are of varying types and sizes and may be concerned that requiring the adoption of such best practices might not be appropriate for all. However, we request comment on whether we should require implementation of certain aspects of a particular guidance document. If so, please explain which aspect(s) we should require, the rationale, and information about the burden of implementing such aspect(s).

A. Section 160.103—Definitions

1. Current Provision

Electronic media are used by many health care organizations to process, transmit, and maintain ePHI. As defined by the Security Rule, the term “electronic media” ^[334] encompasses both (1) electronic storage material on which data is or may be electronically recorded; and (2) transmission media used to exchange information already in electronic storage media. It specifically excludes certain transmissions, such as those of paper, via facsimile (“fax”), and voice, via telephone, from being considered transmissions via electronic media if the information being exchanged did not exist in electronic form immediately before the transmission.

2. Issues To Address

The Department revised the definition of “electronic media” in 2013 by replacing the term “electronic storage media” with “electronic storage material” in recognition that there may be storage material other than “media” that houses electronic data in the future.^[335] At that time, the Department said that a fax machine accepting a hardcopy document for transmission is not a covered transmission even though the document may have originated from printing from an electronic file.^[336] In response to commenter concerns, we also clarified that ePHI maintained, intentionally or otherwise, in a photocopier, fax machine, or other device is subject to the Security Rule and reminded regulated entities that they should be aware of the capabilities of such devices with respect to their ability to maintain ePHI.^[337] Additionally, a regulated entity should consider the appropriateness of implementing security measures that account for such capabilities.^[338]

Since 2013, the role technology plays in the storage and transmission of information has changed, as have the types of media used to store and transmit such information. For example, traditional landlines ^[339] are rapidly being replaced with electronic communication technologies, such as Voice over internet Protocol (VoIP),^[340] and mobile technologies that use electronic media, such as the internet, intra- and extranets, cellular, and Wi-Fi.^[341] Some current electronic technologies that regulated entities use for remote communications may include communication applications on a smartphone or another computing device, VoIP technologies, technologies that electronically record or transcribe a telehealth session, and messaging services that electronically store audio messages. The definition of electronic media does not account for these changes because it excepts ( print page 922) transmissions via fax, and of voice, via telephone, from transmissions via electronic media, nor does the definition take into consideration new and emerging technologies. Accordingly, the Department believes that it is appropriate to reconsider this definition.

3. Proposals

The Department proposes to modify the definition of “electronic media” as follows. First, the Department proposes to revise paragraph (1) of the definition to clarify that electronic media includes not only media on which data may be recorded, but also media on which data may be maintained or processed.

Generally, data is either at rest, in transit, or in process ( e.g., being worked on, in use, being modified in memory, or being updated).^[342] After the data is no longer in use, it is either maintained or transmitted. It is especially important for entities to protect data in process because generally, data must be unencrypted to be processed, making this a time when it is particularly vulnerable to a breach or other security incident.^[343] To that end, the Department's proposal would clarify that the definition includes electronic media that is used to record, maintain, or process data.

The Department also proposes to revise paragraph (1) to clarify and update terminology used in a non-exhaustive list of examples of electronic storage material. Additionally, to ensure that the definition includes future technology, the Department proposes to add to the list of examples “any other form of digital memory or storage” on which data may be recorded, maintained, or processed.

As discussed above, traditional landlines and fax machines are rapidly being replaced with electronic communication technologies and mobile technologies that use electronic media. The Security Rule applies when a regulated entity uses such electronic communication technologies. Therefore, regulated entities using telephone systems and fax equipment that transmit ePHI need to apply the Security Rule safeguards to those technologies.^[344] Accordingly, in paragraph (2), we propose to revise the description of “transmission media” to recognize that data is transmitted almost exclusively in electronic form today. The limited exception to this would be data that is handwritten on paper and hand-delivered or mailed, such that the data is never on electronic storage material. Additionally, the Department proposes to include public networks in the examples of transmission media and to remove the sentence that describes transmissions that are not considered transmissions via electronic media. By making these changes, we would reflect technology's evolution since 2013.

We also propose to make a technical correction to paragraph (2) of the definition, consistent with a revision made in the 2013 Omnibus Rule to paragraph (1).^[345] Specifically, the Department proposes to replace the term “electronic storage media” with “electronic storage material” in paragraph (2) to clarify the connection between definitions of electronic storage material and transmission media. We neglected to make this change in 2013 when we replaced “electronic storage media” with “electronic storage material” in paragraph (1), which means that paragraph (2) relies on a term that is no longer defined. This technical correction we propose is consistent with how the Department has interpreted the definition of transmission media and the connection between it and electronic storage material since the change was made in 2013.

4. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether the proposed modifications accurately capture current use of electronic media.

b. Whether the proposed modifications allow for future technological innovation.

c. Whether there are other types of electronic storage material that the Department should include in the non-exhaustive list of examples.

d. Whether there are other types of transmission media that the Department should include in the non-exhaustive list of examples.

B. Section 164.304—Definitions

Section 164.304 includes definitions for key regulatory terms in the Security Rule. The Department proposes to add ten new defined terms and to modify the definitions of fifteen existing terms. The proposed new regulatory terms would be: Deploy, Implement, Electronic information system, Multi-factor authentication, Relevant electronic information system, Risk, Technical controls, Technology asset, Threat, and Vulnerability. The definitions we propose to modify are for the following terms: Access, Administrative safeguards, Authentication, Availability, Confidentiality, Information system, Malicious software, Password, Physical safeguards, Security or Security measures, Security incident, Technical safeguards, User, and Workstation. Generally, the Department is proposing to add or modify regulatory terms that would either clarify how regulated entities should apply the standards and implementation specifications or modernize the rule to better account for changes in the environment in which health care is provided.

1. Clarifying the Definition of “Access”

a. Current Provision and Issues To Address

The Security Rule defines the term “access” as the ability or means necessary to perform a set of activities describing how a user may interact with a system resource.^[346] These activities are reading, writing, modifying, communicating data/information, or otherwise using any component of an information system. The definition applies only to the Security Rule, not to the Breach Notification Rule or the Privacy Rule.

The term “access” defines the scope of some key regulatory provisions in the Security Rule. For example, whether a person meets the definition of a “user” is determined based on whether their access to information or a component of the regulated entity's information system is authorized.^[347] The definition ( print page 923) of the term “security incident” requires consideration of whether a person attempted to access or accessed information without authorization.^[348] To determine whether a regulated entity complied with the administrative safeguard standard for workforce security, the Department must consider to what extent a regulated entity established policies and procedures for ensuring that workforce members have appropriate access to ePHI.^[349]

The current definition is expansive but not fully representative of how users could interact with information today. As discussed above, users create, receive, maintain, and transmit information in more ways now than they did ten years ago. Thus, the Department believes that it is critical for the Department to consider modifying the definition of this term to adequately reflect the current electronic environment.

b. Proposal

The Department proposes to expand the list of activities that should be considered under the term by adding the activities of “deleting” and “transmitting.” The Department also proposes to replace “system resource” with “component of an information system” to rely on an already defined term, “information system.” The proposed modification would clarify that the term includes any and all components of an information system and an information system as a whole. Additionally, the Department believes that a component of an information system better describes how the term access applies today because it is inclusive of hardware, software, and people, as opposed to only the inherent capabilities that contribute to performance, such as system memory and hard disk space.

2. Clarifying the Definition of “Administrative Safeguards”

a. Current Provision and Issues To Address

Administrative safeguards are administrative actions, policies, and procedures to manage the selection, development, implementation, and maintenance (including reviewing and modifying) of security measures to protect ePHI.^[350] Administrative safeguards also manage the conduct of the regulated entity's workforce in relation to the protection of ePHI. Under the Security Rule, there are minor inconsistencies in language between the definitions of the types of safeguards, which might lead to uncertainty about how to interpret the terms and lead to unintended consequences. For example, the definitions of “administrative safeguards” and “physical safeguards” use “are,” while the definition of technical safeguards uses “means.” ^[351]

In addition, the existing definition of “administrative safeguards” does not expressly relate the administrative actions to the policies and procedures addressing the activities covered by the definition, nor does it make clear that the policies and procedures are in addition to the administrative actions. The same is true for the definitions of physical and technical safeguards. Further, the definition of “administrative safeguards” does not expressly mention managing updates and modifications to safeguards.

b. Proposal

To address the minor inconsistencies between the definitions of the safeguards and to ensure that each safeguard is afforded an equal weight of importance, the Department proposes similar but minor changes across the definitions. The Department proposes to add the word “related” to the definition here, and below to add the words “and related” when necessary, to more clearly connect the components that make up safeguards. In the case of administrative safeguards, the Department's proposal relates administrative actions to administrative policies and procedures. The Department believes that this change would reduce confusion and improve clarity about compliance obligations. We are proposing a similar change to the definitions of physical safeguards and technical safeguards below. Additionally, we are proposing to clarify that maintenance includes updating and modifying with respect to administrative safeguards.

3. Clarifying the Definition of “Authentication”

a. Current Provision and Issues To Address

The Security Rule defines authentication as corroboration that a person is the one claimed. By limiting the definition of authentication to persons, the current definition neglects to acknowledge the importance to the security of ePHI of authenticating technology assets that are components of a regulated entity's electronic information systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI, or that the regulated entity intends to connect to such electronic information systems.^[352] Absent such authentication, a bad actor could add technology assets ( e.g., software) to a regulated entity's electronic information systems that enable the bad actor to compromise the security of ePHI.

b. Proposal

To modernize the definition of authentication to reflect best practices in cybersecurity today, the Department proposes to clarify the definition to mean corroboration that either a person or technology asset is the one they are claiming to be. The modified definition would also improve readability with minor changes in wording. The Department believes as proposed, the revised definition would more accurately reflect the role played by technology assets in electronic information systems today. For example, a covered health care provider permits individuals to access their own PHI using an application that connects to the software that runs the covered health care provider's patient portal. Not only must the individual be authenticated as a user, but the application must be authenticated such that the covered entity's software can verify that the application is what it claims to be. In another example, a portable technology asset for retrieving and storing PHI in the cloud must be authenticated before retrieving data from cloud storage.

4. Clarifying the Definition of “Availability”

a. Current Provision and Issues To Address

“Availability” is defined in the Security Rule as the property that data or information is accessible and usable upon demand by an authorized person. Although not intended, the current definition could be read to limit the scope of availability only to authorized persons. And yet, it is equally important to ensure that authorized technology assets, such as connected medical devices, software, and workstations, ( print page 924) have access on demand to ePHI to carry out their functions.

b. Proposal

Given the increased connectivity of the health care environment, the Department proposes to clarify the definition of availability by specifying that availability means the property that data or information is accessible and usable upon demand by not only an authorized person, but also an authorized technology asset. In so doing, the Department is not changing the meaning of availability, but rather clarifying its scope.

5. Clarifying the Definition of “Confidentiality”

a. Current Provision and Issues To Address

Similar to the definition of availability, the definition of the term “confidentiality” could be read as limited to the property that data or information is not made available or disclosed to unauthorized persons or processes. Read that way, the definition does not reflect today's health care environment in which data and information may be accessed through any component of an interconnected electronic information system.

b. Proposal

The Department proposes to clarify the definition of confidentiality to specify that it means the property that data or information is not made available or disclosed to unauthorized persons, technology assets, or processes.

6. Adding Definitions of “Deploy” and “Implement”

a. Issues To Address

The Security Rule directs regulated entities to implement technical policies and procedures and assumes that such implementation requires the installation and configuration of technical safeguards.^[353] OCR is concerned, based on its investigations and compliance reviews, that some regulated entities may interpret the regulatory requirement to implement technical policies and procedures to mean that a regulated entity is only required to establish written policies and procedures about technical requirements, but need not then apply effective, automated technical policies and procedures to all ePHI throughout the regulated entity's enterprise. For example, in M.D. Anderson, the court stated that the encryption requirement at 45 CFR 164.312(a)(2)(iv) requiring a regulated entity to implement a mechanism to encrypt ePHI does not “require a covered entity to warrant that its mechanism provides bulletproof protection of `all systems containing ePHI.' Nor does it require covered entities to warrant that all ePHI is always and everywhere `inaccessible to unauthorized users.' ” ^[354] Further, the court added that the requirement does not “say anything about how effective a mechanism must be, how universally it must be enforced, or how impervious to human error or hacker malfeasance it must be.” ^[355]

Therefore, the Department believes it is necessary to add definitions that distinguish between implementation of the administrative and technical safeguards by separately describing how regulated entities can comply with requirements to implement technical safeguards and install technical solutions.

b. Proposal

The Department proposes to define the term “deploy” to identify a specific type of “implementation.” We believe that the new term and definition would help to better describe the compliance obligations for implementation specifications related to the use of technology for securing the confidentiality, integrity, or availability of ePHI. As proposed, the definition would require a regulated entity to ensure that technology is in place, configured for use, and actually in use and operational throughout the regulated entity. The Department's proposed use of the term helps illustrate its purpose and utility in clarifying that policies and procedures, while necessary, are insufficient to meet requirements for technical safeguards.

For example, the Department is proposing to create a new requirement for regulated entities to verify that business associates have deployed technical safeguards—that is, the technology is configured and operational, not only addressed in policies and procedures.^[356] In another example, the Department is proposing new implementation specifications under the access control standard that would require a regulated entity to deploy technical controls for relevant electronic information systems so that the system is configured and applied to limit access to only users and technology assets that have been granted access rights.^[357] In the automatic logoff implementation specification for that same standard, the Department is proposing to replace the requirement to implement electronic procedures for terminating an electronic session with a requirement to deploy technical controls that terminate an electronic session after a period of inactivity.^[358] In each case, the technical controls must not only be configured for use, but they also must be applied to and in effect in all ePHI and relevant electronic information systems.

The Department proposes to define the term “implement” to clarify that a safeguard must be put into place and be in effect throughout the enterprise, as opposed to only some components of a regulated entity's relevant information systems ( e.g., some laptops or servers) or applied to a subset of ePHI. The Department also proposes the term to further clarify what it means to configure and put technology, technical controls, and related policies and procedures into effect and be in use, operational, and function as expected throughout the regulated entity's enterprise ( i.e., deploy) as compared to putting into place and making effective administrative or physical safeguards. Further, the Department proposes to expressly clarify that implement also means that a safeguard must function as expected. Under this proposal, if adopted, we would not consider a safeguard to be implemented if it is not functioning in the manner in which it is expected.

For example, a regulated entity's administrative policy requiring it to take action to prevent infections from malicious software is not implemented until it is applied throughout the enterprise, meaning that the entity has ensured that anti-malware protections have been put into place on all relevant electronic information systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI throughout the enterprise.

Similarly, to operationalize such a policy, the regulated entity must deploy technology assets and/or technical controls to block such software according to its technical policies and ( print page 925) procedures. In this regard, the proposed term “deploy” clarifies that the technology assets or technical control must be put into place, configured, and actually work ( i.e., function in the manner expected of the technology or technical control) throughout a regulated entity, in addition to the relevant policy and procedures being applied across a regulated entity. To implement a policy and procedure is separate from the implementation of a technology asset or technical control but in both cases, the underlying requirement is application across the enterprise.

7. Adding a Definition of “Electronic Information System”

a. Issues To Address

The current Security Rule includes explicit requirements for regulated entities to protect electronic information systems by implementing policies and procedures to limit physical access to such systems ^[359] and by implementing technical policies and procedures for electronic information systems that maintain ePHI to allow access to only persons or technology assets that have been granted access rights pursuant to 45 CFR 164.308(a)(4).^[360] Further, the physical measures, policies, and procedures that meet the definition of physical safeguards are specifically limited to those that protect regulated entities' electronic information systems and related buildings and equipment.^[361] And yet, the Security Rule does not explicitly define this term. Instead, it assumes that the definition is easily understood to be a subset of information system, a broad term that is not limited by the boundaries of the Security Rule. The Department believes that regulated entities would benefit from additional clarity regarding the definition of this term, given its foundational nature.

b. Proposal

The Department proposes to add a definition of “electronic information system” to better distinguish the concept from the broader category of an information system. Accordingly, the Department would limit the definition to an interconnected set of electronic information resources under the same direct management control that shares common functionality. Under this proposal, an electronic information system generally would include technology assets, such as hardware, software, electronic media, data, and information.

8. Modifying the Definition of “Information System”

a. Current Provision and Issues To Address

As discussed above, the Department seeks to clarify the scope of an information system, as compared to an electronic information system. We believe that it would be beneficial to align the common elements of these terms and clarify the relationship between them, given their importance to compliance with requirements of the Security Rule. Additionally, the changes in the environment, such as the shift to cloud-based computing, may raise questions regarding the Department's interpretation of “direct management control.”

b. Proposal

Accordingly, the Department proposes to modify the definition of “information system,” to clarify that an information system “generally”, not just “normally,” includes hardware, software, data, communications, and people. The Department believes this proposed modification, combined with the existing broad reference to “resources,” more accurately reflects the typical components of an information system and the full extent of resources that are addressed by the Security Rule. We also propose to remove “applications” from the list of technology assets that are generally included in an information system because applications are a type of software, making the inclusion of applications redundant. This proposed modification would not alter our interpretation that an information system includes applications.

We use this opportunity to affirm that a technology asset may be included as part of the information systems of multiple regulated entities where such regulated entities all have direct management control over the technology asset. For example, both a health care provider and a cloud-based EHR vendor have direct management control over the ePHI in the cloud-based EHR. Accordingly, such ePHI generally is part of both the information system of the health care provider and of the cloud-based EHR vendor. Additionally, the EHR that is used to create, receive, maintain, or transmit ePHI, regardless of whether it is accessed using software installed on the health care provider's workstation(s) or an internet browser, generally is also part of the information system of both entities because both the health care provider and the vendor have direct management control over the EHR.

9. Modifying the Definition of “Malicious software”

a. Current Provision and Issues To Address

Persons seeking unauthorized access to data and information are increasingly sophisticated. Their methods of attempting to gain such access can take many forms and result in a wide array of harms, as discussed above. One of the methods they use is through the introduction of malicious software (also referred to as malware) into an electronic information system. As the sophistication of bad actors has increased, so has the variety of types of malicious software that they use to access electronic information systems. The Security Rule defines malicious software but limits it to software designed to damage or disrupt a system. The regulatory text provides only one example of malicious software in regulatory text—a virus.

b. Proposal

The Department proposes to replace the current definition of malicious software with one that would be consistent with how cybersecurity experts define the term today.^[362] Specifically, we propose to define it to mean software or firmware intended to perform an unauthorized action or activity that will have adverse impact on an electronic information system and/or the confidentiality, integrity, or availability of electronic protected health information. This proposal would therefore clarify that malicious software could include either software or firmware and that the negative effects of the malicious software may not be limited to damaging or disrupting a system. Rather, effects of the software could be intended to have any type of adverse impact on an electronic information system and/or the confidentiality, integrity, or availability of ePHI. The Department also proposes to include in regulatory text a non-exhaustive list of examples, such as viruses, worms, Trojan horses, spyware, and some forms of adware, to assist regulated entities in understanding what constitutes malicious software.

( print page 926)

10. Adding a Definition of “Multi-Factor Authentication” (MFA)

a. Issues To Address

The Security Rule includes several technical safeguard provisions that require regulated entities to identify and authenticate persons accessing information and systems to protect ePHI. Section 164.312(a)(2)(1) includes the standard that requires a regulated entity to implement technical policies and procedures that limit access to ePHI to only those persons or software programs that have been granted access rights, while 45 CFR 164.312(d)(2), the standard for person or entity authentication, requires a regulated entity to implement procedures to verify that a person seeking access to ePHI is the one claimed.

Historically, regulated entities relied on combinations of usernames and passwords to identify users and authenticate users to the system. We recognize that such combinations are insufficient to secure sensitive information and that more sophisticated mechanisms for doing so have been developed. As a best practice for managing cyber threats, most cybersecurity frameworks, including those discussed above, recommend that organizations adopt solutions that rely on multiple factors to identify and authenticate users. For example, the HHS 405(d) Program's “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients” ^[363] recommends a layered approach to cyber defense ( i.e., if a first layer is breached, a second exists to prevent a complete breach).^[364] It further provides that MFA as a source of identity and access security control is an important means to control access to infrastructure and conduct proper change management control.^[365] The Department's CPGs ^[366] identify MFA as an essential goal and a critical, additional layer of security for the protection of assets and accounts that are directly accessible from the internet.^[367] The Department has also explained in guidance that weak authentication processes leave organizations vulnerable to intrusion, while effective authentication ensures that only authorized entities may access information systems and data.^[368] Additionally, CISA has issued recommendations for implementing MFA, specifically MFA solutions that are phishing resistant to protect against disclosures of authentication data to a bad actor.^[369]

b. Proposal

The Department proposes to define the term “Multi-factor authentication” to provide regulated entities with a specific level of authentication for accessing relevant electronic information systems.^[370] Regulated entities would be required to apply this proposed definition when implementing the proposed rule's specific requirements for authenticating users' identities through verification of at least two of three categories of factors of information about the user. The proposed categories would be:

• Information known by the user, including but not limited to a password or personal identification number (PIN).
• Item possessed by the user, including but not limited to a token or a smart identification card.
• Personal characteristic of the user, including but not limited to fingerprint, facial recognition, gait, typing cadence, or other biometric or behavioral characteristics.

MFA relies on the user presenting at least two factors. Authentication that relies on multiple instances of the same factor, such as requiring a password and PIN, is not MFA because both factors are “something you know.” ^[371] For example, where MFA is deployed, users could seek access by entering a password. However, without the entry of at least a second factor such as a token ^[372] or smart identification card, the user is not granted access and the password is useless by itself. Cybercriminals seeking access to MFA-protected information systems require significantly more resources to launch the attack because there are multiple data points required to succeed.^[373]

The Department proposes that the personal characteristics that could be used as factors would include both physical characteristics, such as fingerprints or facial identifiers, and behavioral characteristics, such as a user's gait or typing cadence.^[374]

11. Clarifying the Definition of “Password”

a. Current Provision and Issues To Address

The Security Rule currently defines “password” as confidential authentication information composed of a string of characters.^[375] The definition provides no further regulatory instruction on what constitutes a “character” for purpose of compliance.

b. Proposal

The Department proposes to add examples to the definition to further clarify what constitutes a character, and adds “such as letters, numbers, spaces, and other symbols” to the existing definition. The Department believes that regulatory examples would provide necessary context for regulated entities that deploy safeguards involving passwords. ( print page 927)

12. Clarifying the Definition of “Physical Safeguards”

a. Current Provision and Issues To Address

“Physical safeguards” encompass the physical measures, policies, and procedures that protect a regulated entity's electronic information systems and related buildings and equipment from natural and environmental hazards, and unauthorized intrusion. As discussed within the definition of administrative safeguards, the Department believes that it is necessary to reduce minor inconsistences in language between the definitions of the types of safeguards. Additionally, the definition of physical safeguards relies on an undefined term (“buildings”), despite the existence of a defined term (“facilities”) that has an equivalent meaning.

b. Proposal

The Department proposes to clarify that the policies and procedures referred to in the definition are those that specifically are related to physical measures, and to replace “buildings” with “facilities” because facility is a defined term under the Security Rule and has an equivalent meaning.^[376] The Department intends and has always intended the physical safeguards to apply to any location where a regulated entity might possess ePHI, including the physical premises and interior and exterior of a building, and any location that might affect the confidentiality, integrity, or availability of ePHI. Additionally, given the mobility of technology today, including workstations that may access ePHI, we believe it would be more appropriate to use the term facility to make clear that the physical safeguards are to apply throughout the premises of the regulated entity. For the same reasons discussed above, we also propose to clarify that the physical safeguards serve to protect relevant electronic information systems, as we propose to define the term elsewhere in this NPRM, rather than all electronic information systems. Further, the Department proposes to better standardize the administrative, physical, and technical safeguard requirements by using defined terms where they exist.

13. Adding a Definition of “Relevant Electronic Information System”

a. Issues To Address

The Security Rule requires a regulated entity to ensure the confidentiality, integrity, and availability of all of the ePHI it creates, receives, maintains, or transmits.^[377] To protect the ePHI as required, a regulated entity must also protect the electronic information systems that create, receive, maintain, or transmit ePHI and the electronic information systems that otherwise affect the confidentiality, integrity, or availability of ePHI. The Department believes that regulated entities are not consistently protecting ePHI in a manner that is consistent with their Security Rule obligations and believes that it is necessary to clarify the scope of those obligations. We believe that creating a new defined term for the electronic information systems to which the Security Rule requirements apply will help achieve this goal by ensuring that regulated entities fully understand how their technology assets and the architecture of their electronic information systems affect the confidentiality, integrity, and availability of ePHI.

b. Proposal

The Department proposes to add and define the term “relevant electronic information system” to mean an electronic information system that creates, receives, maintains, or transmits ePHI or that otherwise affects the confidentiality, integrity, or availability of ePHI. We believe that distinguishing between a relevant electronic information system and an electronic information system, as proposed, would further clarify the scope of regulated entities' compliance obligations, including the obligation of regulated entities to understand the relationship between their various electronic information systems and the confidentiality, integrity, and availability of ePHI.

The Department believes it is important to clarify that the requirements of the Security Rule do not only apply to electronic information systems that create, receive, maintain, or transmit ePHI. After all, cybercriminals may be able to access ePHI by leveraging vulnerabilities in some electronic information systems that do not themselves create, receive, maintain, or transmit ePHI where such information systems are connected to or otherwise affect electronic information systems that do create, receive, maintain, or transmit ePHI. For example, while a payment processing system used in a covered entity's food and beverage outlets or gift shops may not create, receive, maintain, or transmit ePHI, it may affect the confidentiality, integrity, or availability of ePHI in certain circumstances, such as where such systems are connected to the same network as servers that contain ePHI.^[378] Accordingly, we would interpret an electronic information system as otherwise affecting the confidentiality, integrity, or availability of ePHI if it is insufficiently segregated physically and electronically from an electronic information system that creates, receives, maintains, or transmits ePHI or one that otherwise affects the confidentiality, integrity, or availability of ePHI.

An electronic information system would also fit the category of “otherwise affecting” if it contains information that relates to an electronic information system that creates, receives, maintains, or transmits ePHI or to another electronic information system that otherwise affects the confidentiality, integrity, or availability of ePHI. For example, a compromised electronic information system used to provide administrative functions, such as user authentication or management of storage area network infrastructure, that does not contain ePHI may allow unauthorized access to ePHI (affecting the confidentiality of ePHI) or disruption of storage configuration data (affecting the integrity and availability of ePHI). An electronic information system that is not connected to a covered health care provider's EHR but that maintains user IDs and passwords for the EHR also may not create, receive, maintain, or transmit ePHI; however, the confidentiality, integrity, or availability of the ePHI in the EHR would be affected if an unauthorized person gained access to that electronic information system. And the same is true for an electronic information system that contains the decryption keys for a regulated entity's encryption algorithms. Thus, it is important that administrative, physical, and technical safeguards be implemented not only for electronic information systems that create, receive, maintain, or transmit ePHI, but also for electronic information systems that otherwise affect the confidentiality, integrity, or availability of ePHI. ( print page 928)

14. Adding a Definition of “Risk”

a. Issues To Address

The Security Rule does not currently include a definition for the term “risk.” The Department considered defining it when it first promulgated the final rule in 2003, but declined to do so because it determined that the term was commonly understood.^[379] However, the Department now believes that the lack of a definition may affect the clarity of some key requirements for regulated entities. Such requirements include conducting a risk analysis to assess the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the regulated entity ^[380] and implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with the general rules at 45 CFR 164.306(a).^[381]

One of the ways NIST defines the term is as “a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.” ^[382] This and other NIST definitions serve as helpful references for the Department when considering how to define the term within the rule.

b. Proposal

The Department proposes to define “risk” as the extent to which the confidentiality, integrity, or availability of ePHI is threatened by a potential circumstance or event. The Department believes that defining the term would clarify several existing and proposed provisions of the Security Rule, such as the factors regulated entities must consider when determining the security measures they will implement ^[383] and the importance and purpose of conducting the required risk analysis.^[384]

15. Clarifying the Definitions of “Security or Security Measures” and “Security Incident”

a. Current Provision and Issues To Address

The Security Rule defines “security or security measures” as encompassing all of the administrative, physical, and technical safeguards in an information system.^[385] The definition implies that the safeguards must be part of the information system, as opposed to something that may be applied or done to a system to protect the confidentiality, integrity, and availability of ePHI.

The rule also defines “security incident” as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The existing definition does not make clear that a security incident may result from two types of behaviors—those related to attempted or successful but unauthorized access, use, disclosure, modification, or destruction of information in an information system, and those that are related to the attempted or successful unauthorized interference with system operations in an information system. In other words, a security incident may directly touch upon information in a system or interfere with the operations of the system itself. The Department believes that it is necessary to clearly convey the distinct types of incidents to regulated entities to ensure that regulated entities implement and deploy safeguards that address both concerns.

b. Proposal

The Department proposes to modify the definition of “security or security measures” to clarify that security or security measures may not only exist in information systems but may also be applied to information systems.^[386] This clarification would better reflect the multi-layered approach to cybersecurity recommended by experts to address the concerns facing regulated entities today. For example, a regulated entity may determine that it is necessary to apply access controls and encryption mechanisms through an external mechanism, such as added firewall technology,^[387] that is applied to the system, rather than technical controls that are embedded within the system or components of the system. The Department believes that the proposed definition would provide a more complete instruction.

The Department proposes to reorganize the definition of “security incident” into two numbered paragraphs to delineate the two separate categories of security incidents. We also propose to clarify that in both instances, the definition applies when the described action affects an information system and regardless of whether an attempt to affect the information in the system or interfere with system operations is successful or not.

16. Adding Definitions of “Technical Controls”

a. Issues To Address

Throughout the technical safeguards provisions in 45 CFR 164.312, the Department directs regulated entities to implement technical policies and procedures. The court in M.D. Anderson interpreted technical policies and procedures as written policies and procedures on technical matters.^[388] This interpretation does not reflect the Department's intent for technical safeguards to include policies and procedures that rely on technology or technological solutions for implementation.^[389] We believe that the court's interpretation could have significant consequences for the confidentiality, integrity, and availability of ePHI.

b. Proposal

The Department proposes to add and define the term “technical controls” to help regulated entities better understand what we mean by technical safeguards for purposes of complying with the Security Rule. We propose to define technical controls as technical mechanisms contained in the hardware, software, or firmware components of an electronic information system that are primarily implemented and executed by the electronic information system to protect it and the data within the electronic information system. The Department believes that adding this term would better convey the expectation that a regulated entity is ( print page 929) required to deploy technical safeguards across its enterprise by, among other things, configuring and using technical mechanisms in the hardware, software, and firmware components of its relevant electronic information systems to protect ePHI and electronic information systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, availability, or integrity of ePHI.

17. Modifying the Definition of “Technical Safeguards”

a. Current Provision and Issues To Address

The current definition of “technical safeguards” includes the technology and policy and procedures for its use that protect ePHI and control access to it.^[390] As discussed above, the Department believes that there is an immediate need to modernize and update the definition to better reflect the role technology plays in protecting ePHI and the technical components of information systems, versus the role of policies and procedures. This would complement our effort to clarify the relationship between technology and the implementation of technical policies and procedures.

b. Proposal

The Department proposes to modify the definition of “technical safeguards” to expressly include “technical controls.” We also propose to add language that would clarify that the technology, technical controls, and related policies and procedures in this category govern the use of the technology to protect and control access to ePHI. The proposed changes also would improve the consistency of language across the safeguard provisions and rule.

18. Adding a Definition of “Technology Asset”

a. Issues To Address

Throughout the Security Rule, standards and implementation specifications list the components of electronic information systems to which its requirements apply. Based on the Department's enforcement experience, we believe that it would be beneficial to more clearly distinguish between the requirements that apply to all components of an electronic information system and those that only apply to certain components. Additionally, we believe it would be beneficial to distinguish between requirements that apply specifically to each particular component of an electronic information system and those that apply to the electronic information system as a whole.

b. Proposal

The Department proposes to define the term “technology asset” to mean the components of an electronic information system, including but not limited to hardware, software, electronic media, information, and data. In so doing, we would clarify which Security Rule requirements apply to all of the components of electronic information systems as opposed to those that apply only to certain components, and which requirements apply to each particular components and which apply to the entire electronic information system.

For example, understanding the risks and vulnerabilities to a regulated entity's ePHI requires a thorough understanding of the components of its electronic information systems, the electronic information systems themselves, how they are connected, and how ePHI moves through those systems. Thus, by requiring a regulated entity to conduct an inventory of its technology assets and to create a network map of its electronic information systems, we clarify that a regulated entity is obligated to consider not only its electronic information systems as a whole, but also the components within those electronic information systems and their functions.

19. Adding a Definition of “Threat”

a. Issues To Address

Addressing threats to the confidentiality, integrity, and availability of ePHI is a key function of the Security Rule, but the rule does not define “threat.” The concept of threat also underlies the Department's proposed definition of “risk” defined above and forms the basis of a key proposed implementation specification associated with the standard for risk analysis.^[391]

b. Proposal

The Department proposes to define the term “threat” to mean any circumstance or event with the potential to adversely affect the confidentiality, integrity, or availability of ePHI. This proposal is similar to NIST's varying definitions of threat, edited to apply specifically to health care and the type of information addressed by the Security Rule.^[392] Under this proposal, we would construe the term to apply broadly to include threats caused by, or existing because of, a variety of circumstances that specifically could affect the security of ePHI. Hackers, malicious insiders, and malicious software are examples of threat sources.

20. Clarifying the Definition of “User”

a. Current Provision and Issues To Address

The Department first defined the term “person” in the HIPAA Rules as part of the 2003 “Civil Money Penalties: Procedures for Investigations, Imposition of Penalties, and Hearings” interim final rule to distinguish a “natural person” who could testify in the context of administrative proceedings from an “entity” (defined therein as a “legal person”) on whose behalf a person would testify.^[393] Although they were both published in 2003, the interim final rule was published two months after the Security Rule. Thus, when the Security Rule was published in 2003, it was necessary to specify that the term “user” included both natural persons and entities, but we believe that this is no longer the case because the current definition of “person” includes natural persons as well as entities.^[394]

b. Proposal

The Department proposes to clarify the definition of “User” by removing the reference to an entity.^[395] Because the definition of “person” includes an entity, including entity in the definition of “user” is redundant and could cause confusion. We believe that this is a technical correction because it would not change how the Department has interpreted the term.

21. Adding a Definition of “Vulnerability”

a. Issues To Address

The term “vulnerability” is currently not defined in the Security Rule.

The Department previously explained that although some cyberattacks may be sophisticated and exploit previously unknown vulnerabilities ( i.e., zero-day attacks), most can be prevented or mitigated by addressing known vulnerabilities.^[396] For example, ( print page 930) exploitable vulnerabilities exist across many components of IT infrastructures including, but not limited to, servers, desktops, mobile device operating systems, web software, and firewalls.^[397] To mitigate against intrusions and hacking threats, the Department has recommended that regulated entities install vendor patches, make software updates, and monitor sources of cybersecurity alerts describing new vulnerabilities, such as the NIST National Vulnerability Database ^[398] and CISA's Known Exploited Vulnerabilities Catalog.^[399]

b. Proposal

The Department proposes to define vulnerability by adopting substantially the same definition as NIST (a “weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source”) ^[400] with minor changes to clarify how it applies to regulated entities and ePHI. The definition, if adopted as proposed, would then form the basis for understanding key assessment and mitigation strategies proposed in this NPRM, such as risk analyses,^[401] patch management,^[402] and vulnerability management and scans.^[403]

22. Clarifying the Definition of “Workstation”

a. Current Provision and Issues To Address

The Department currently defines the term “workstation” to mean an electronic computing device and provides the examples of technology that dominated the health care environment in 2003 and 2013, such as a laptop, desktop computer, and other device that performs similar functions, and electronic media stored in its immediate environment.^[404] Workstations are essential for workforce members to perform their assigned functions, such as clinicians entering an individual's health history and treatment plan or billing staff preparing claims. Workstations are one of the key entry points for users to access a regulated entity's information systems. Thus, the Security Rule contains provisions requiring that regulated entities secure not only their information systems, but also individual workstations.^[405] However, as discussed above, the health care environment has changed. It now includes both the physical and virtual environment and is replete with mobile devices and other types of devices that may serve as multi-functional workstations. Clinicians and other workforce members often rely on smart phones, smart watches, tablets, laptops, and even personal digital assistants, among other devices. These devices have proliferated, and so has their ability to perform a wide variety of functions with increasing sophistication. The Department believes that it is necessary to update the definition to reflect the evolved nature of the landscape.

b. Proposal

In recognition of this changed environment, the Department proposes to modify the definition of workstation to provide additional examples of what constitutes a workstation. Specifically, we propose to add the examples of a server, virtual device, and a mobile device such as a smart phone or tablet. Virtual devices could include a virtual medical device, virtual server, or virtual desktop computer. The proposed definition also would clarify that technology properly considered as a “workstation” is not limited to the proposed regulatory examples.

23. Request for Comment

The Department requests comment on all the foregoing proposed definitions, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether any of the proposed definitions would be problematic for regulated entities or result in unintended adverse consequences. If so, please explain.

b. Whether the Department should consider an alternative definition for any terms the Department proposes to define in the rule. If the answer is yes, please propose such an alternative definition and a reference or supporting rationale.

c. Whether the Department should define any additional terms within the rule. If the answer is yes, please propose such additional terms and definitions, along with any reference or supporting rationale.

d. With respect to the definitions of “information system” and “electronic information system,” the extent of a covered entity's direct management control over applications in cloud computing environments, such as a cloud-based EHR system.

e. With respect to the definitions of “information system” and “electronic information system,” the extent of a business associate's direct management control over applications in cloud computing environments, where the business associate is the cloud service provider.

f. Whether defining the term “technical controls” and adding it to the definition of “technical safeguards” would more clearly explain the requirements of 45 CFR 164.312.

g. Whether defining “implement” and “deploy” as we propose would more clearly explain the differences between what is expected of regulated entities with respect to administrative and physical safeguards and technical safeguards. To the extent that the proposals would not clarify the differences, please provide alternative solutions.

C. Section 164.306—Security Standards: General Rules

1. Current Provisions

Section 164.306 applies to regulated entities and includes the general rules for security standards. Generally, paragraph (a) codifies HIPAA statutory requirements for safeguarding ePHI.^[406] Under these rules, regulated entities are required to do all of the following:

• Ensure the confidentiality, integrity, and availability of all ePHI the regulated entity creates, receives, maintains, or transmits.^[407]

• Protect against reasonably anticipated threats or hazards to the security or integrity of such information.^[408]

• Protect against any reasonably anticipated uses or disclosures of such information not permitted by the Privacy Rule.^[409]

• Ensure that workforce members comply with the Security Rule.^[410]

Paragraph (b) of this section permits regulated entities to determine the most ( print page 931) appropriate security measures for protecting ePHI and their information systems. Accordingly, 45 CFR 164.306(b)(1) permits regulated entities to use any security measures to reasonably and appropriately implement the standards and implementation specifications of the Security Rule, while 45 CFR 164.306(b)(2) contains the factors that regulated entities are to consider when deciding which security measures to use. This paragraph furthers the aim of HIPAA's requirement for the security standards to take into account certain factors by providing for their consideration by regulated entities.^[411] Accordingly, 45 CFR 164.306(b)(2) directs regulated entities to take these factors into account when determining the manner in which they will comply with the security standards and implementation specifications.

Section 164.306(c) requires regulated entities to comply with the administrative, physical, and technical safeguard standards in sections 45 CFR 164.308, 164.310, and 164.312 respectively, and with standards for organizational requirements and policies, procedures, and documentation requirements in sections 45 CFR 164.314 and 164.316. This provision is followed by paragraph (d), which explains that regulated entities are required to implement a specific implementation specification if described as “required.” If the implementation specification is described as “addressable,” regulated entities are required to implement the implementation specification if it is reasonable and appropriate to do so; or, if it is not reasonable and appropriate, document why and implement an equivalent alternative measure.

Finally, the maintenance provision at 45 CFR 164.306(e) requires regulated entities to review and modify security measures implemented under the Security Rule as needed to continue providing reasonable and appropriate protection of ePHI. It also requires regulated entities to update documentation of such security measures in accordance with the requirements for documentation at 45 CFR 164.316(b)(2)(iii).

2. Issues To Address

We believe that we can improve consistency in language between this section and other Security Rule provisions and better align this section with statutory terms and intent. For example, we are concerned that regulated entities are misinterpreting 45 CFR 164.306(a) to apply the requirements of the Security Rule to only some ePHI, rather than all ePHI. This interpretation could lead to inadequate protection of ePHI and relevant electronic information systems.^[412] We also believe that consistency in language facilitates clear understanding and less ambiguity about how regulated entities must apply Security Rule standards.

Flexibility and scalability are among the Security Rule's defining characteristics, and we intend to preserve those elements to the extent possible. However, we believe that in this era of increased reliance on technology, more sophisticated cyber capabilities, and increasing cyberattacks, it is critical for regulated entities to implement and deploy strong security measures to protect ePHI and related information systems. We are concerned that regulated entities have focused their attention primarily on the cost of security measures, rather than considering the reasonableness and appropriateness of security measures in the context of all of the listed factors, including the probability and criticality of potential risks to ePHI.^[413] Further, the Department believes that providing additional clarity would improve the ability of regulated entities to evaluate security measures for the protection of ePHI and the ability of a security measure to facilitate a regulated entity's recovery from emergencies and to support continued operations. With these proposed modifications, the Department seeks to ensure that regulated entities' reliance on the Security Rule's flexibility and scalability does not come at the expense of adequate security. The current regulation's framework in 45 CFR 164.306(b) lacks any express factor that would require an evaluation of the effectiveness of the security measures in supporting the resiliency of the regulated entity.

The Department has explained in regulation and guidance the difference between required and addressable implementation specifications. The meaning of “required” is clear. Regarding “addressable,” we previously explained that its purpose is to provide regulated entities flexibility with respect to implementation compliance.^[414] We also previously explained that a regulated entity must assess whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its environment, and if it is, the regulated entity must implement the addressable implementation specification.^[415] However, the Department remains concerned that regulated entities believe that flexibility overrides the need for them to protect all ePHI and do not uniformly treat addressable implementation specifications as needing to be met if they are reasonable and appropriate. OCR's enforcement experience and interaction with regulated entities causes us to believe that “addressable” is misunderstood to be optional, leading regulated entities to choose not to adopt the implementation specification, even when it would be reasonable and appropriate for them to do so.^[416]

In 2022, NCVHS recommended that the Department eliminate the choice to not implement a specification or alternative, and instead require that regulated entities implement the specification or adopt a documented reasonable alternative.^[417] According to a survey referenced by NCVHS, despite private sector and government efforts to address a changing cybersecurity landscape, the majority of health care entities have failed to maintain a comprehensive security program and ( print page 932) continue to neglect people and process measures necessary for a comprehensive security program.^[418] NCVHS also pointed to a continued failure of regulated entities to develop adequate incident recovery plans and to assess their vulnerability to cyberattacks grounded in social engineering.^[419] Finally, NCVHS opined that the current structure of the Security Rule is inadequate to protect U.S. health care infrastructure because it does not require regulated entities “to adopt the basic building blocks of good security hygiene, or a documented, reasonable alternative.” ^[420]

We share NCVHS' concerns and believe that we must squarely confront the problem of regulated entities treating addressable implementation specifications as optional. Relatedly, we also believe that we must consider modifying the Security Rule to set an acceptable minimum level of security specifications. Circumstances have changed sufficiently since 2003 such that we now believe that good cyber hygiene requires regulated entities to implement more than the implementation specifications that we originally mandated.^[421] Indeed, we believe that it requires compliance with all of the standards and implementation specifications we are proposing, with specific, limited exceptions.

We also believe that the current maintenance requirement in 45 CFR 164.306(e) would benefit from increased specificity in light of the dramatic transformation of the health IT environment discussed above. For example, providing the frequency with which regulated entities must review and update their security measures would improve the security of ePHI and regulated entities' compliance with the Security Rule. The Security Rule's maintenance requirement would be further strengthened by requiring regulated entities to test their security measures to verify their sufficiency, and by clarifying the Department's expectations regarding documentation. Regulated entities' lack of documentation about how they implement security measures makes it difficult for them to know what security measures they have in fact implemented and to demonstrate compliance with the requirements of the Security Rule. Finally, the maintenance requirement in 45 CFR 164.306(e) is not included in or designated as a Security Rule standard, although it explicitly references the overarching documentation requirements in 45 CFR 164.316(b)(2)(iii). Thus, there is overlap between the two sections that may be causing confusion regarding the obligations of regulated entities to maintain security measures.

3. Proposals

a. Section 164.306(a)—General Requirements

The Department proposes to expand the introductory language to the general requirements provision at 45 CFR 164.306(a) to clarify the extent to which the general requirements apply to the obligations of regulated entities with respect to ePHI that they create, receive, maintain, or transmit.

Under the proposal, the Department would clarify that the general requirements apply to “all” ePHI. Additionally, the Department proposes to move language from paragraph (a)(1) to paragraph (a) to further emphasize that regulated entities must apply the requirements of the Security Rule to protect all of the ePHI they create, receive, maintain, or transmit. We also propose to clarify that “each” regulated entity would be required to apply the obligations in paragraphs (a)(1) through (4) to all ePHI it creates, receives, maintains, or transmits. The Department believes that this proposal would stress to regulated entities that each and every covered entity and business associate would be responsible for ensuring it meets Security Rule requirements with respect to all ePHI.

The Department believes this proposed change would also help address issues raised by current interpretations of the Security Rule that suggest that its plain wording may not require regulated entities to fully implement each security measure to protect all ePHI. Thus, the Department's proposed language would clarify that a security measure must be implemented such that it protects the security of all ePHI and all information systems that affect the confidentiality, integrity, and availability of ePHI.

Additionally, the Department proposes to modify the general requirements of paragraph (a)(2) to require each regulated entity to protect against any reasonably anticipated threats or hazards to the confidentiality, integrity, or availability of all ePHI, instead of to the security or integrity of ePHI. We believe that this proposal would better align this requirement with the general requirement at 45 CFR 164.306(a)(1), and confidentiality, integrity, and availability are generally considered the three basic elements of security.^[422]

Additionally, the Department proposes a minor change to paragraph (a)(3) to refer specifically to ePHI, rather than using a more general term. We believe that both proposals would constitute technical revisions and that neither would alter the meaning of 45 CFR 164.306(a)(2) or (3), respectively.

Finally, the Department proposes to modify paragraph (a)(4) so that each regulated entity would be required to ensure that its workforce complies not only with the Security Rule, but also all administrative, physical, and technical safeguards implemented in accordance with this subpart.

These proposals would better align the language of the general requirements in paragraph (a) of 45 CFR 164.306 with the statute ^[423] and 45 CFR 164.530(c).^[424] These proposals are also consistent with our proposals to revise the introductory language for each of the safeguard provisions to clarify the provisions therein would be the minimum regulated entities are to implement, i.e., that the security measures required by the Security Rule constitute a floor of protections, not a ceiling.

b. Section 164.306(b)—Flexibility of Approach

The Department's proposals generally retain the flexible approach described in paragraph (b). As discussed above, the Security Rule carefully balances the benefits of safeguarding against risks to security and the burdens of implementing protective measures by, for example, enabling regulated entities to take into account specified factors when determining how to implement security measures in a manner that complies with the Security Rule. To acknowledge the rapid evolution of technology and increasing threats, the Department proposes to clarify ( print page 933) paragraph (b)(1) to provide that regulated entities are to apply reasonable and appropriate security measures to implement the standards and implementation specifications of the Security Rule. This proposal, if adopted, would replace the existing paragraph providing for regulated entities' reasonable and appropriate implementation of standards and implementation specifications, which could be misinterpreted to mean that a regulated entity may determine that implementation itself is unreasonable or inappropriate in some circumstances. That has never been the case. Thus, the proposed modification would clarify that implementation is not optional based on whether a regulated entity believes it is reasonable and appropriate; to the contrary, a regulated entity is required to implement the standards and implementation specifications and must adopt reasonable and appropriate security measures that allow the entity to achieve such implementation. The proposed clarification would comport more precisely with the statute, which requires regulated entities to maintain “reasonable and appropriate” safeguards.^[425]

The Department also proposes to add a new element to the list of factors that regulated entities must take into account when deciding whether a particular security measure ( e.g., a technical control) is reasonable and appropriate for implementing a standard and its associated implementation specifications: the effectiveness of the security measure in supporting the resiliency of the regulated entity. A regulated entity would be required to consider this factor, in addition to the existing factors, for example, when choosing a specific encryption solution that allows the entity to meet the proposed requirement to encrypt ePHI, which will help prevent an unauthorized user from accessing the entity's ePHI; or when developing its security incident plan or disaster recovery plan, which will help ensure that the regulated entity can recover data or reestablish data integrity after a security incident or disaster.

The Department proposes at 45 CFR 164.306(b)(2)(v) to require a regulated entity to take into account how effectively its application of a particular security measure to achieve compliance with a standard and its associated implementation specifications would support its resiliency in the face of an event that adversely affects the entity. According to NIST, “information system resilience” addresses how well information systems “continue to (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs.” ^[426] Recently, in this era of rising cybercrime, NIST described “cyber resiliency” as “the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources.” ^[427] Thus, the Department proposes to require a regulated entity to consider the ability of its implementation of a particular security measure to aid it in preventing, withstanding, and recovering from an emergency or other occurrence that affects the confidentiality, integrity, or availability of ePHI, including a successful security incident.

The Department proposes this new requirement to better enable regulated entities to ensure the confidentiality, integrity, and availability of all ePHI that they create, receive, maintain, or transmit. The general rules require regulated entities to not only prevent threats and hazards to the confidentiality and integrity of ePHI, but also to ensure the availability of ePHI, even during a security incident that has the potential to severely hinder the ability of a regulated entity to provide health care or to bring it to a standstill. This new factor would require a regulated entity to consider whether a particular approach to complying with a standard and the associated implementation specifications can help it recover from an emergency or other occurrence, in addition to maintaining operations throughout the event. The Department proposes this factor to complement its proposals to strengthen the standards for security incident procedures ^[428] and contingency planning ^[429] and proposals for new standards for patch management ^[430] and vulnerability management,^[431] discussed in detail below. If finalized, these proposals would help to ensure that regulated entities put in place the necessary measures to implement these standards.

The factors contemplate that regulated entities will regularly evaluate the security measures they have applied to comply with the standards and implementation specifications based on the technology available and known risks and vulnerabilities at the time of the evaluation. The Department expects that when the existing factors are considered with the factor proposed in this NPRM, a regulated entity would be required to consider whether a specific technical control has become sufficiently ubiquitous such that choosing not to adopt it would be unreasonable.

c. Section 164.306(c)—Standards and Implementation Specifications

To address the Department's concerns regarding the apparent misunderstanding by regulated entities of “addressable,” we propose to modify 45 CFR 164.306(c) and (d) by collapsing the separate paragraphs into one paragraph (c) to address both standards and implementation specifications and to remove the distinction between “addressable” and “required” implementation specifications. Instead, proposed paragraph (c), if adopted, would require regulated entities to comply with both the standards and implementation specifications. The Department believes that eliminating the distinction would make clear to regulated entities what has always been a requirement—that the Security Rule sets a floor for cybersecurity protections and that its flexibility is in allowing them to choose the manner in which they meet the standards and implementation specifications, not whether they meet them. The proposed change also would be consistent with NCVHS' recommendation to require regulated entities to meet certain minimum cybersecurity hygiene requirements.^[432]

The Department acknowledges that proposing to remove the addressability distinction is a change from the approach adopted in the 2003 Final Rule. At that time, we explained that the decision to include addressable implementation specifications was made to provide additional flexibility to ( print page 934) covered entities.^[433] In this rulemaking, the Department proposes to strengthen protections and address evolving cybersecurity threats. While we acknowledge that this proposal would reduce the Security Rule's flexibility, we believe that it is necessary to do so to achieve HIPAA's purpose of an efficient and effective health care system that relies on the secure electronic exchange of ePHI. Importantly, removing the distinction between required and addressable would not eliminate all of the Security Rule's flexibility and scalability. Instead, it would simply clarify for regulated entities where the floor of protection must lie, and regulated entities must implement solutions that meet that floor, taking into consideration their needs and capabilities. For example, a small or rural health care provider must implement a solution that ensures the protection of ePHI in the manner required by the Security Rule, but the specific solution that it chooses would reflect consideration of its particular circumstances, including available resources. In some cases, a small or rural health care provider might opt to implement a cloud-based EHR or other software solution that could reduce the health care provider's need to separately invest in data storage, backup systems, and IT personnel. And in other circumstances, a small or rural health care provider might choose to contract with a third party to provide IT support, rather than hiring its own workforce members to perform such functions.

The Department also proposes to delete the maintenance provision at 45 CFR 164.306(e). Instead, as discussed in greater detail below, we propose to clearly delineate maintenance implementation specifications for specific standards, when applicable. We believe this approach would clarify how maintenance requirements relate to specific security measures and would remove any ambiguity about the need for regulated entities to regularly review, test, and modify measures as reasonable and appropriate. We further discuss maintenance provisions below for each safeguard.

4. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether removing the distinction between required and addressable implementation specifications would result in unintended negative consequences for regulated entities. If so, please explain and provide a recommendation for how the Department should clarify how regulated entities are required to implement the security measures described in the proposed rule.

b. Whether the Department should include other factors in 45 CFR 164.306(b) for regulated entities to consider when selecting the security measures that they will implement to meet the requirements of the Security Rule. If so, please explain.

c. Whether the factor proposed by the Department at proposed 45 CFR 164.306(b)(2)(v) would help regulated entities identify reasonable and appropriate security measures.

d. Whether the Department's proposals sufficiently clarify that a regulated entity is expected to modify its security measures in response to changes in the environment in which health care is provided, including, but not limited to, the adoption of new technology, the evolution of existing technology, and the emergence of new threats.

e. Whether the proposals sufficiently take into account the needs and capabilities of small health care providers and rural health care providers, as required by the statute. If not, please explain and include a recommendation for ways that the Department could better account for such needs and capabilities while adequately ensuring the confidentiality, integrity, and availability of ePHI that they create, receive, maintain, or transmit. The recommendations should also take into consideration the effect of the actions taken by small and rural health care providers on the ePHI that is created, received, maintained, or transmitted by other regulated entities with whom small and rural health care providers interact.

D. Section 164.308—Administrative Safeguards

Section 164.308 of title 45 CFR contains the administrative safeguards that a regulated entity must implement, consistent with the general requirements described in 45 CFR 164.306. All of the standards and implementation specifications found in the Administrative Safeguards section refer to administrative functions, such as policies and procedures that must be in place for the management and execution of security measures.

1. Current Provisions

a. Section 164.308(a)

Section 164.308(a) contains most of the standards and associated implementation specifications that are categorized as administrative safeguards. The standards for administrative safeguards are as follows:

• Security management process.
• Assigned security responsibility.
• Workforce security.
• Information access management.
• Security awareness and training.
• Security incident procedures.
• Contingency plan.
• Evaluation.

The standard for security management process at 45 CFR 164.308(a)(1)(i) requires regulated entities to implement policies and procedures to prevent, detect, contain, and correct security violations. The Security Rule directs regulated entities as to how they are to comply with the standard for security management process through four implementation specifications. Section 164.308(a)(1)(ii)(A) requires regulated entities to conduct a risk analysis that accurately and thoroughly assesses potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI they hold. The implementation specification for risk management at 45 CFR 164.308(a)(1)(ii)(B) requires regulated entities to implement measures to reduce risks and vulnerabilities, such as those identified in the risk analysis, to a reasonable and appropriate level. Under 45 CFR 164.308(a)(1)(ii)(C), regulated entities are required to apply appropriate sanctions against workforce members who fail to comply with applicable security policies and procedures, while the implementation specification for information system activity review at 45 CFR 164.308(a)(1)(ii)(D) requires regulated entities to implement procedures to regularly review information system activity records.

The standard for assigned security responsibility at 45 CFR 164.308(a)(2) requires regulated entities to identify a security official who is responsible for the development and implementation of the policies and procedures that are required by this section. There are no implementation specifications associated with this standard.

Section 164.308(a)(3)(i) contains the standard for workforce security and requires regulated entities to implement policies and procedures to ensure that their workforce members have appropriate access to ePHI, which includes preventing workforce members who do not have authorized access from ( print page 935) obtaining it. The implementation specifications associated with this standard address the need to implement certain procedures regarding workforce member access to ePHI. Section 164.308(a)(3)(ii)(A) addresses the implementation of procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it might be accessed. The implementation specification for workforce clearance procedure at 45 CFR 164.308(a)(3)(ii)(B) addresses the implementation of procedures to determine that a workforce member's access to ePHI is appropriate, while 45 CFR 164.308(a)(3)(ii)(C) addresses the implementation of procedures for terminating a workforce member's access to ePHI when their employment or similar arrangement ends or as required by the regulated entity's workforce clearance procedures.

Under 45 CFR 164.308(a)(4)(i), the standard for information access management, a regulated entity is required to implement policies and procedures for authorizing access to ePHI in a manner that is consistent with the requirements of the Privacy Rule, that is, only when such access is appropriate based on the user or recipient's role ( i.e., “role-based access”). This interpretation is consistent with the Privacy Rule's standard that limits most uses and disclosures of PHI to the “minimum necessary” to accomplish the purpose of the use or disclosure.^[434] The standard for information access management has three implementation specifications: paragraph (a)(4)(ii)(A) requires a health care clearinghouse that is part of a larger organization to implement policies and procedures to protect ePHI from unauthorized access by that organization; paragraph (a)(4)(ii)(B) addresses implementation of policies and procedures for granting access to ePHI, for example, through a workstation, program, or other mechanism; and paragraph (a)(4)(ii)(C) addresses the implementation of policies and procedures that, based on the regulated entity's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, program, or other process.

Section 164.308(a)(5)(i) contains the standard for security awareness and training. This standard requires a regulated entity to implement a security awareness and training program for all workforce members, including management. There are four associated implementation specifications that address the need for regulated entities to implement the following:

• Periodic security updates.^[435]

• Procedures for guarding against, detecting, and reporting malicious software.^[436]

• Procedures for monitoring log-in attempts and reporting discrepancies.^[437]

• Procedures for creating, changing, and safeguarding passwords.^[438]

The standard for security incident procedures at 45 CFR 164.308(a)(6)(i) requires a regulated entity to implement policies and procedures to address security incidents. The one implementation specification associated with this standard, 45 CFR 164.308(a)(6)(ii), requires regulated entities to identify and respond to suspected or known security incidents; to mitigate, to the extent practicable, harmful effects of security incidents that are known to the regulated entity; and to document security incidents and their outcomes.

Under the standard for contingency planning at 45 CFR 164.308(a)(7)(i), a regulated entity is required to establish, and implement as needed, policies and procedures for responding to an emergency or other occurrence that damages systems that contain ePHI. The standard includes five implementation specifications at 45 CFR 164.308(a)(7)(ii). The first, paragraph (a)(7)(ii)(A), requires a regulated entity to establish and implement procedures to create and maintain exact copies of ePHI that are retrievable.^[439] Paragraph (a)(7)(ii)(B) requires a regulated entity to establish, and implement as needed, procedures to restore any lost data.^[440] Paragraph (a)(7)(ii)(C) requires a regulated entity to establish, and implement as needed, procedures to enable continuation of critical business processes for protecting the security of ePHI while the regulated entity is operating in emergency mode. Paragraph (a)(7)(ii)(D) addresses the implementation of procedures for periodic testing and revision of contingency plans, and paragraph (a)(7)(ii)(E) addresses the assessment of the relative criticality of specific applications and data in support of other contingency plan components.

The standard for evaluation at 45 CFR 164.308(a)(8) requires a regulated entity to periodically perform a technical and nontechnical evaluation that establishes the extent to which the regulated entity's security policies and procedures meet the requirements of the Security Rule. The initial evaluation is to be based upon the standards implemented under the Security Rule, while subsequent evaluations are to be conducted in response to environmental or operational changes affecting the security of ePHI.

b. Section 164.308(b)

Section 164.308(b) contains the administrative safeguards that apply to the relationships between regulated entities. Specifically, 45 CFR 164.308(b)(1) permits a covered entity to engage a business associate to create, receive, maintain, or transmit ePHI on the covered entity's behalf when it obtains satisfactory assurances (consistent with the organizational requirements for business associate agreements or other arrangements in 45 CFR 164.314(a)) that the business associate will appropriately safeguard the ePHI. Similarly, under 45 CFR 164.308(b)(2), a business associate may retain a subcontractor to create, receive, maintain, or transmit ePHI on its behalf if the business associate obtains satisfactory assurances through a business associate agreement or other arrangement that the subcontractor will appropriately safeguard the information. Section 164.308(b)(3) requires that the contract or other arrangement be in writing.^[441]

2. Issues To Address

The Security Rule administrative standards are comprehensive, but our experience has demonstrated that they have been misunderstood by some regulated entities, especially regarding how compliance with the standards and implementation specifications must be integrated with the general requirements in 45 CFR 164.306, including the requirement in 45 CFR 164.306(e) that a regulated entity must review and modify security measures. Section 164.306 does not explicitly reference specific security measures, and we are concerned that recent caselaw has highlighted conditions that may cause regulated entities to misinterpret regulatory text that connects the maintenance provision at 45 CFR 164.306(e) with the documentation requirements in 45 CFR 164.316 and the administrative safeguards. Through OCR's educational and enforcement efforts, we also have observed inadequacies in compliance with security management processes. For example, some regulated entities have ( print page 936) incorrectly interpreted the standards to not require implementing administrative safeguards, such as risk analyses, for all relevant electronic information systems. Some regulated entities have not documented in writing their policies, procedures, plans, and analyses.^[442] As discussed above, many mistakenly treated “addressable” implementation standards as optional.^[443] Enforcement experience has shown that regulated entities generally do not perform all elements of the risk management process that are fundamental to protecting the confidentiality, integrity, and availability of ePHI and to cybersecurity more broadly.

In addition, since the Security Rule was issued in 2003 and revised in 2013, newer, more protective security technology has become widely available to regulated entities, and best practices for securing electronic information have evolved. NIST has published numerous guides, including its recent Cybersecurity Framework 2.0, providing resources for establishing and implementing policies and practices to better manage cybersecurity risks.^[444] OCR is drawing upon its enforcement experience, as well as best practices, guidelines, processes, and procedures for improving cybersecurity to propose changes to these standards to better protect ePHI that a regulated entity creates, receives, maintains, or transmits. We believe that these proposals would help ensure that regulated entities implement compliance activities that are consistent with recommendations made by NIST, the HHS 405(d) program, and standards setting bodies regarding cybersecurity.

Because business associates are directly liable for compliance with the Security Rule, in our 2013 Security Rule revisions we did not require covered entities to implement any additional safeguards to ensure that their business associate is in fact in compliance.^[445] However, OCR has learned through its enforcement experience that many covered entities have entrusted ePHI to business associates that are not employing appropriate safeguards. Some business associates have such market power that covered entities may believe they have no alternative to using their services, even if they have concerns about the safeguards employed by the business associate. The Department is concerned by the breaches experienced by business associates and the effects of such breaches on the confidentiality, integrity, and availability of ePHI.^[446]

3. Proposals

a. Section 164.308—Administrative Safeguards

Throughout this section, the Department proposes to add explicit maintenance requirements to certain standards to address concerns that regulated entities may be misinterpreting the regulatory text that connects the maintenance provision at 45 CFR 164.306(e) with the administrative safeguards. These proposals would clarify that a regulated entity is required to maintain certain security measures, and that where a regulated entity is required to maintain a particular security measure, it is required to review and test such measure on a specified cadence, and to modify the measure as reasonable and appropriate. Testing of particular security measures, such as technical controls or policies and procedures, would include verifying that the security measures work as designed and that workforce members know how to implement them. For example, written policies and procedures can be tested through various methods including, but not limited to: simulating security events that mimic real-world attacks to assess how effectively employees follow incident response and security procedures; conducting knowledge assessments after training on policies and procedures; and reviewing system logs and access records to evaluate whether policies and procedures governing access to ePHI are being followed. We would expect a regulated entity to take the results of the required tests into consideration when determining whether it is reasonable and appropriate to modify its security measures, as well as the actions that would be expected of a regulated entity that is similarly situated based on the results of such tests.

We also propose to modify certain administrative safeguards to clarify the obligations of a regulated entity to ensure the confidentiality, integrity, and availability of ePHI by securing its relevant electronic information systems—that is, its electronic information systems that create, receive, maintain, or transmit ePHI and those that otherwise affect its confidentiality, integrity, or availability—and the technology assets in its relevant electronic information systems.

b. Section 164.308(a)

The Department proposes to modify the general language at 45 CFR 164.308(a) to clarify the connection between the general rules for security standards at 45 CFR 164.306, the standards for policies and procedures and documentation requirements at 45 CFR 164.316, and the standards for the administrative safeguards under 45 CFR 164.308(a). We also propose to clarify that regulated entities would be required to implement all of the administrative safeguards of the Security Rule to protect the confidentiality, integrity, or availability of all ePHI that they create, receive, maintain, or transmit. Thus, when read together, proposed 45 CFR 164.308(a) and 164.316(a) would require that a regulated entity implement and document, in writing, its implementation of the administrative safeguards required by the Security Rule. These requirements set the baseline for administrative safeguards. Nothing in this NPRM would prevent a regulated entity from implementing additional administrative safeguards, provided that those additional safeguards do not conflict with any requirements in the Security Rule.

The proposed changes are discussed in greater detail below.

c. Section 164.308(a)(1)(i)—Standard: Technology Asset Inventory

We propose to modify 45 CFR 164.308(a)(1) by elevating to standard-level status the existing implementation specifications for the standard for security management process at 45 CFR 164.308(a)(1)(ii)(A) through (D), and deleting the existing standard. Doing so would highlight the importance of these elements and permit us to add implementation specifications that detail our expectations for compliance with those elements. We believe that providing more specificity in our requirements would help regulated entities better understand their compliance responsibilities for ( print page 937) safeguarding ePHI. These proposals are consistent with current guidance, as described below.

In place of the existing standard for security management process, we propose a standard at 45 CFR 164.308(a)(1)(i) that would require a regulated entity to conduct and maintain an accurate and thorough written technology asset inventory and a network map of its electronic information systems and all technology assets that may affect the confidentiality, integrity, or availability of ePHI. The inventory forms the foundation for a fulsome and accurate risk analysis. A regulated entity must identify its information systems that create, receive, maintain, or transmit ePHI and all technology assets, as we propose to define them in 45 CFR 164.304, that may affect ePHI in such information systems in order to secure them. Regulated entities cannot understand the risks to the confidentiality, integrity, and availability of their ePHI without a complete understanding of these assets. We believe that this proposal would clarify compliance expectations and provide increased protections for the confidentiality, integrity, and availability of ePHI. Consistent with practices previously highlighted in guidance, regulated entities would be required by this proposal to conduct and maintain an accurate and thorough written inventory of technology assets.

The standard would also require each regulated entity to determine the movement of ePHI through, into, and out of its information systems and to describe such movement in a network map. A regulated entity's network map would reflect where its technology assets are, for example, physically located at the regulated entity's worksite, or accessed through the cloud. As another example, a covered entity might determine that ePHI is created, received, maintained, or transmitted by one or more offshore business associates ( i.e., persons that are located outside of the U.S.) for such services as claims processing, call center staffing, and technical support, activities that inherently involve ePHI. The technology assets used by the business associate to create, receive, maintain, or transmit ePHI are not a part of the covered entity's electronic information system, but do affect the confidentiality, integrity, or availability of ePHI and so would be required to be included in the network map of the covered entity.^[447] Such assets would be considered part of the business associate's electronic information systems and therefore would need to be included in both its technology asset inventory and network map. Any technology assets used by the covered entity to create, receive, maintain, or transmit ePHI to the business associate would need to be accounted for in both its technology asset inventory and network map. Such technology assets would not be part of the business associate's technology asset inventory, but would need to be included on its network map.

This proposed standard aligns with the Department's enhanced CPG for Asset Inventory, which requires that a regulated entity identify assets to more rapidly detect and respond to potential risks and vulnerabilities,^[448] and is consistent with NCVHS' recommendation to require regulated entities to identify where all PHI is stored and to collect data on applications and systems used by the organization to create a systems inventory.^[449]

In 2003, the Department elected not to require regulated entities to conduct an inventory because we believed that regulated entities would understand that such an inventory is a vital component of the risk analysis, making it redundant of other requirements of the Security Rule.^[450] The Department and NIST have provided extensive guidance, described below, about how to conduct such inventories as part of compliance with 45 CFR 164.308. However, nearly 20 years of enforcement experience indicates that regulated entities routinely disregard this part of the process. OCR's investigations frequently find that organizations lack sufficient understanding of where all the ePHI entrusted to their care is located.^[451]

Understanding one's environment—particularly how ePHI is created and enters an organization, how ePHI flows through an organization, and how ePHI leaves an organization—is crucial to understanding the risks ePHI is exposed to throughout an organization.^[452] According to the NIST Cybersecurity Framework 2.0, having a comprehensive understanding of the organization's assets ( e.g., data, hardware, software, systems, facilities, services, people), suppliers, and related cybersecurity risks enables a regulated entity to prioritize its efforts consistent with its risk management strategy and its mission needs.^[453]

The proposed standard would be accompanied by three implementation specifications. Under the proposed implementation specification for inventory at proposed 45 CFR 164.308(a)(1)(ii)(A), the regulated entity would be required to establish a written inventory that contains the regulated entity's technology assets. Technology assets are components of an electronic information system, including but not limited to hardware, software, electronic media, information, and data. The written inventory would be required to include technology assets that create, receive, maintain, or transmit ePHI and those that do not but that may affect the confidentiality, integrity, or availability of ePHI.^[454] It would also be required to include the identification, version, person accountable for, and location of each of the assets or information system components.^[455]

The proposed implementation specification for network map at proposed 45 CFR 164.308(a)(1)(ii)(B) would require a regulated entity to develop a network map that illustrates the movement of ePHI throughout its electronic information systems, including but not limited to how ePHI enters and exits such information systems, and is accessed from outside of such information systems.

Under the proposed implementation specification for maintenance at proposed 45 CFR 164.308(a)(1)(ii)(C), a regulated entity would be required to review and update the written inventory of technology assets and the network map in the following circumstances: (1) on an ongoing basis, but at least once every 12 months; and (2) when there is a change in the regulated entity's environment or operations that may affect ePHI. Such a change in the ( print page 938) regulated entity's environment or operations would include, but would not be limited to, the adoption of new technology assets; the upgrading, updating, or patching of technology assets; newly recognized threats to the confidentiality, integrity, or availability of ePHI; a sale, transfer, merger, or consolidation of all or part of the regulated entity with another person; a security incident that affects the confidentiality, integrity, and availability of ePHI; and relevant changes in Federal, State, Tribal, or territorial law. For example, a dissolution or bankruptcy of the regulated entity would require the regulated entity to review and update its inventory and network map. For another example, if a State implemented regulations specifying cybersecurity requirements for all hospitals, these proposed specifications would require a regulated entity in that State to review and update its inventory and network map considering implementation of the State regulations by the regulated entity or other persons whose activities may affect movement of ePHI throughout its electronic information systems.^[456]

The proposed standard is consistent with the NIST Cybersecurity Framework Identify function, Asset Management (ID.AM) category, which describes inventorying hardware and software and mapping communication and data flows to create and maintain an asset inventory that can be used in a risk analysis process. For example, the Cybersecurity Framework recommends that when creating an asset inventory, organizations should include all of the following, as applicable:

• Hardware assets that comprise physical elements, including electronic devices and media, that make up an organization's networks and systems. This may include mobile devices, servers, peripherals (e.g., printers, USB hubs), workstations, removable media, firewalls, and routers.
• Software assets that are programs and applications that run on an organization's electronic devices. Well-known software assets include anti-malicious software tools, operating systems, databases, email, administrative and financial records systems, electronic medical/health record systems, and clinical decision support tools, including those that rely on AI. Though lesser known, there are other programs important to IT operations and security such as backup solutions, and other administrative tools that also should be included in an organization's inventory.
• Data assets that include ePHI that an organization creates, receives, maintains, or transmits on its network, electronic devices, and media. How ePHI is used and flows through an organization is important to consider as an organization conducts its risk analysis.^[457]

Where multiple persons have control over a technology asset, all persons that have control should include the asset in both their technology asset inventories and on their network maps. For example, where a covered entity contracts with a cloud-based EHR vendor, both the covered entity and the EHR vendor have control over the ePHI in the EHR. Thus, the ePHI in the EHR and the EHR should be included in the technology asset inventories and network maps of both the covered entity and the cloud-based EHR vendor. Where the technology assets are controlled entirely by another person, such as the servers controlled by a cloud-based provider of data backup services, the technology assets would not be considered part of a health care provider's electronic information systems, and therefore would not have to be included in its technology asset inventory. However, the data backup provider would have to be included in the health care provider's network map.

When creating or maintaining a technology asset inventory that can aid in identifying risks to ePHI, regulated entities should consider their technology assets that may not create, receive, maintain or transmit ePHI, but that may affect technology assets that do so.^[458] Assets within an organization that do not create, receive, maintain, or transmit ePHI may still present opportunities for intruders to enter the regulated entity's electronic information systems, which could lead to risks to the confidentiality, integrity, or availability of an organization's ePHI. For example, consider a smart device that is connected to the internet ( e.g., connected to the Internet of Things ^[459] (IoT)) and provides access to facilities for maintenance personnel to control and monitor an organization's heating, ventilation, and air conditioning (HVAC). Although it may not maintain or process ePHI, such a device potentially can present serious risks to the security of ePHI in an organization's information systems. Unpatched IoT devices with known vulnerabilities, such as weak or unchanged default passwords installed on a network without firewalls, network segmentation, or other techniques that deny or impede an intruder's lateral movement, can provide an intruder with access to an organization's relevant electronic information systems. The intruder may then leverage this access to conduct reconnaissance and further penetrate an organization's network and potentially compromise ePHI.

The risks and deficiencies OCR has observed in its enforcement experience persuades us that we must consider adding an express requirement for a regulated entity to conduct an accurate and thorough written inventory of its technology assets and create a network map.

d. Section 164.308(a)(2)(i)—Standard: Risk Analysis

After a regulated entity conducts a written inventory of its technology assets and creates its network map, it is critical for it to identify the potential risks and vulnerabilities to its ePHI. Conducting a risk analysis is necessary to adequately protect the confidentiality, integrity, and availability of ePHI because it provides the basis for determining the manner in which the regulated entity will comply with and carry out the other standards and implementation specifications in the Security Rule.^[460] Basic questions that a regulated entity would consider when conducting a risk analysis that is compliant with the Security Rule include: ^[461]

• Have you identified all the ePHI that you create, receive, maintain, or transmit?
• What are the external sources of ePHI? For example, do vendors or consultants create, receive, maintain, or transmit ePHI?
• What are the human, natural, and environmental threats to information systems that contain ePHI? ( print page 939)
• What are the risks posed by legacy devices, including any risks that would be posed by replacing legacy devices with new ones?

There are numerous methods of performing a risk analysis, and there is no single method or “best practice” that guarantees compliance with the Security Rule.^[462] The Department has issued multiple guidance documents and tools for regulated entities to help them implement risk analyses,^[463] and several versions of its Security Risk Assessment Tool, a desktop application that walks users through the process of conducting a risk assessment.^[464] NIST has published numerous guides for risk assessment over the past two decades,^[465] in addition to reference materials it has developed in collaboration with the Department, including a toolkit and a crosswalk between the Security Rule to NIST Cybersecurity Framework,^[466] and “how to” guides on risk analysis.^[467] In February 2024, NIST released a new guide that provides resources for implementing a Security Rule risk analysis.^[468] Consistent with previous Department guidance, the guide describes key elements in a comprehensive risk assessment process, that include the following:

• Prepare for the assessment by conducting a technology asset inventory.^[469] Determine whether ePHI is transmitted to external third parties, such as cloud service providers or others. The regulated entity can also examine how access to ePHI is controlled and whether ePHI is encrypted at rest and in transit. The scope of a risk assessment should include both the physical boundaries of a regulated entity's location and a logical boundary that includes any devices or media that contain ePHI, including electronic networks through which ePHI is transmitted, regardless of its location.

• Identify reasonably anticipated threats. The list of threat events and threat sources should include reasonably anticipated and probable human and natural incidents that can negatively affect the regulated entity's ability to protect ePHI. The information gathered for the technology asset inventory should be used to identify reasonably anticipated threats to ePHI.
• Identify potential vulnerabilities and predisposing conditions. For any of the various threats identified above to result in a significant risk, each needs a vulnerability or predisposing condition that can be exploited. While it is necessary to review threats and vulnerabilities as unique elements, they are often considered at the same time. Organizations should consider a given loss scenario and evaluate both, such as what threat sources might initiate which threat events or what vulnerabilities or predisposing conditions those threat sources might exploit to cause an adverse effect. From this, the regulated entity should develop a list of vulnerabilities (i.e., flaws or weaknesses) that could be exploited by potential threat sources.
• Determine the likelihood that a threat would exploit a vulnerability. For each threat event/threat source identified, a regulated entity should consider: the likelihood that the threat would occur and the likelihood that an occurred threat would exploit an identified vulnerability and result in an adverse effect. A regulated entity might consider assigning a likelihood value (e.g., “very low,” “low,” “moderate,” “high,” or “very high”) to each threat/vulnerability pairing. As an example, the regulated entity may determine that the likelihood of a phishing attack occurring is very high and that the likelihood of the event exploiting a human vulnerability is moderate, resulting in an overall likelihood rating of high.
• Determine the impact of a threat exploiting a vulnerability. As with likelihood determination, a regulated entity may choose to express this effect in qualitative terms or use any other scale that the entity chooses. When selecting an impact rating, the regulated entity may consider how the threat event can affect the loss or degradation of the confidentiality, integrity, or availability of ePHI. Some tangible impacts can be measured quantitatively in terms of lost revenue, the cost of repairing the system, or the level of effort required to correct problems caused by a successful threat action. Other impacts cannot be measured in specific units (e.g., the loss of public confidence, the loss of credibility, or damage to an organization's interests), but they can be qualitatively described.
• Determine the level of risk to ePHI while considering the information gathered and determinations made during the previous steps. The level of risk is determined by analyzing the values assigned to the overall likelihood of threat occurrence and the resulting impact of threat occurrence.
• Document the risk assessment results. Once the risk assessment has been completed as described above, the results of the risk assessment should be documented. Principally, the regulated entity should document all threat/vulnerability pairs (i.e., a scenario in which an identified threat can exploit a vulnerability) applicable to the organization, the likelihood and impact calculations, and the overall risk to ePHI for the threat/vulnerability pair. Regulated entities should consider sharing the risk assessment results with organizational leadership, whose review can be crucial to the organization's ongoing risk management.

The Department has also published guidance that explains the differences between a risk analysis and a gap analysis, and the use of both in an entity's risk management program.^[470] While a risk analysis is a comprehensive identification of risks and vulnerabilities to all ePHI, a gap analysis typically provides a partial assessment of an entity's enterprise and is often used to provide a high-level overview of what safeguards are in place (or missing) and may also be used to review a regulated entity's compliance with particular standards and implementation specifications of the Security Rule.

Other NIST guidance on conducting risk assessments explains that the result of a risk analysis is a determination of risk posed to the regulated entity's ePHI and related information systems. ^[471] ( print page 940) Consistent with the discussion above, a key step is determining the risk level posed to such ePHI by threats and vulnerabilities and how critical it is to address and mitigate the identified risk. In general, the descriptive words “very high” or “critical” are used to indicate that a threat event could be expected to have multiple severe or catastrophic adverse effects on organizational operations, organizational assets, individuals, other organizations, or the country.^[472] A “high” risk would indicate that a threat event could be expected to have a severe or catastrophic adverse effect on the same, while a “moderate” risk could indicate that the threat event could have a serious adverse effect on the same. Risks that are “low” and “very low” could be expected to have a limited and negligible effect, respectively, on organizational operations or assets, individuals, other organizations, or the country.

The Department believes that determinations of risk level and criticality may vary based on the specific type of regulated entity and the regulated entity's specific circumstances. For example, a health care provider must consider the higher levels of risks to physical and technical security that are created by regular entry and exit of individuals seeking health care and other members of the public into its facilities, creating potentially numerous avenues for access to ePHI through technology assets; in contrast, a health plan that generally does not permit physical entry by individuals into its office building may determine that the risks to ePHI from physical entry by individuals or other members of the public is low because its workforce members do not generally physically interact with the public. As another example, a vulnerability permitting unauthenticated remote code execution on a device connected to a regulated entity's relevant electronic information systems would likely constitute either a high or critical risk. However, should such a device not have the ability to connect to the network, the risk might be low or moderate because the likelihood of triggering a network vulnerability on a non-networked device is low, even though the impact of such trigger might be high. Thus, it is essential that a regulated entity consider its specific circumstances when assessing the criticality of a risk and to address such risks in a manner that is appropriate to its specific facts and circumstances.^[473] In yet another example, a regulated entity in possession of legacy devices or devices that are nearing the end of their lifespan should assess the risks associated with continued use of such devices as part of its risk analysis and ensure that replacement of such devices and/or the implementation of compensating controls are included in its risk management plan.

Despite our having made available an abundance of free and widely-publicized guidance tools, OCR unfortunately has learned through its compliance and enforcement activities that regulated entities often do not perform compliant risk analyses. As discussed above, in 2016 and 2017, the Department conducted audits of 166 covered entities and 41 business associates for their compliance with selected provisions of the HIPAA Rules.^[474] These audits confirmed that only small percentages of covered entities (14 percent) and business associates (17 percent) were substantially fulfilling their regulatory responsibilities to safeguard ePHI they hold through risk analysis activities. Entities generally failed to:

• Identify and assess the risks to all of the ePHI in their possession or even develop and implement policies and procedures for conducting a risk analysis.
• Identify threats and vulnerabilities to consider their potential likelihoods and effects, and to rate the risk to ePHI.
• Review and periodically update a risk analysis in response to changes in the environment and/or operations, security incidents, or occurrence of a significant event.
• Conduct risk analyses consistent with policies and procedures.

Failing to document any efforts to develop, maintain, and update policies and procedures for conducting risk analyses was common. For example, health care providers commonly submitted documentation of some security activities performed by a third-party security vendor, without submitting documentation of any risk analysis that served as the basis of such activities.^[475] Many regulated entities used and relied on outside persons to manage or perform risk analyses for their organizations; however, these outside persons frequently failed to meet the requirements of the Security Rule. Regulated entities also frequently and incorrectly assumed that a purchased security product satisfied all of the Security Rule's requirements.

The responsibility to maintain an appropriate risk analysis rests with the regulated entity. Accordingly, it is essential that regulated entities understand and comply with risk analysis requirements to appropriately safeguard PHI.

Numerous OCR investigations reflect the failure of regulated entities to develop and implement holistic risk analysis programs. For example, OCR's investigation of a health system in the aftermath of a ransomware attack found evidence of potential failures to: conduct a compliant risk analysis to determine the potential risks and vulnerabilities to ePHI in its systems; implement a contingency plan to respond to emergencies, like a ransomware attack, that damage systems that contain ePHI; and implement policies and procedures to allow only authorized users access to ePHI.^[476]

In another recently concluded investigation involving a large medical center, the covered entity reported that over a seven-month period, one of its employees inappropriately accessed the ePHI of more than 12,000 patients and then sold certain patient information to an identity theft ring.^[477] OCR's investigation indicated potential violations of the requirement to conduct an accurate and thorough risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all of the ePHI held by the medical center, as well as the requirement at 45 CFR 164.308(a)(1)(ii)(D) to implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking.

In another case, the OCR settled a ransomware cyberattack investigation with a business associate.^[478] The cyberattack affected the ePHI of over ( print page 941) 200,000 individuals when the business associate's network server was infected with ransomware. It took the company more than 18 months to detect the intrusion, and they only did so when the ransomware was used by the intruder to encrypt the company's files. Among other factors, OCR's investigation found evidence of potential failures to conduct an accurate and thorough risk analysis and to implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

Given the compliance deficiencies that OCR regularly sees—those cited as examples and what OCR has observed more broadly—we believe that stronger requirements coupled with greater specificity regarding the components of a risk analysis would help and encourage regulated entities to appropriately perform such activities. Accordingly, the Department proposes to elevate the requirement to conduct a risk analysis from an implementation specification at 45 CFR 164.308(a)(1)(ii)(A) to a standard at proposed 45 CFR 164.308(a)(2)(i). Under the proposal, and consistent with NCVHS' recommendations,^[479] a regulated entity would be required to conduct an accurate and comprehensive written assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI created, received, maintained, or transmitted by the regulated entity.

The Department proposes eight implementation specifications for the risk analysis standard, consistent with previously issued guidance described above. The proposed implementation specification for a written assessment at proposed paragraph (a)(2)(ii)(A) would require the regulated entity, at a minimum, to perform and document all of the following: ^[480]

• Review the technology asset inventory and the network map to identify where ePHI may be created, received, maintained, or transmitted within its information systems.^[481]

• Identify all reasonably anticipated threats to the confidentiality, integrity, and availability of ePHI that it creates, receives, maintains, or transmits.^[482]

• Identify potential vulnerabilities and predisposing conditions to the regulated entity's relevant electronic information systems—that is, its electronic information systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI.^[483]

• Create an assessment and documentation of the security measures it uses to ensure that the measures protect the confidentiality, integrity, and availability of the ePHI created, received, maintained, or transmitted by the regulated entity.^[484]

• Make a reasonable determination of the likelihood that each identified threat would exploit the identified vulnerabilities.^[485] For example, a regulated entity located on the west coast could consult actuarial tables to reasonably determine the likelihood that an earthquake would affect access to electrical power to maintain its relevant electronic information systems.

• Make a reasonable determination of the potential impact of each identified threat should it successfully exploit the identified vulnerabilities.^[486] For example, the regulated entity described above could make a reasonable determination of how and the extent to which the lack of electrical power caused by an earthquake would affect the availability and integrity of ePHI in its relevant electronic information system.

• Create an assessment of risk level for each identified threat and vulnerability.^[487]

• Create an assessment of risks to ePHI posed by entering into or continuing a business associate agreement or other written arrangement with any prospective or current business associate, respectively, based on the written verification obtained from the prospective or current business associate.^[488]

Under the proposed implementation specification for maintenance at proposed 45 CFR 164.308(a)(2)(ii)(B), a regulated entity additionally would be required to review, verify, and update the written assessment on an ongoing basis, but in any event no less frequently than at least once every 12 months, and in response to a change in the regulated entity's environment or operations that may affect ePHI. As discussed above, a change in the regulated entity's environment or operations that may affect ePHI would include, but would not be limited to, the adoption of new technology assets; the upgrading, updating, or patching of technology assets; newly recognized threats to the confidentiality, integrity, or availability of ePHI; a sale, transfer, merger, or consolidation of all or part of the regulated entity with another person; a security incident that affects the confidentiality, integrity, or availability of ePHI; and relevant changes in Federal, State, Tribal, or territorial law.

e. Section 164.308(a)(3)(i)—Standard: Evaluation

The Department proposes to redesignate the existing evaluation standard at 45 CFR 164.308(a)(8) as 45 CFR 164.308(a)(3)(i) and to revise the redesignated evaluation standard to require the technical and nontechnical evaluation(s) to be in writing and performed to determine whether change in the regulated entity's environment or operations may affect the confidentiality, integrity, or availability of ePHI. Evaluating the effects of a potential change on a regulated entity's environment or operations, including the effects on the confidentiality, integrity, and availability of ePHI, is a critical step in the change control process. An evaluation serves a similar purpose to a risk analysis. However, while a risk analysis looks at the entirety of a regulated entity's enterprise regularly and in response to a change in the regulated entity's environment or operations, an evaluation looks at a specific change that a regulated entity intends to make before the change is made. Thus, this proposal, if adopted, would ensure that a regulated entity proactively considers whether any risks or vulnerabilities to ePHI or its relevant electronic information systems will be introduced by changes it intends to make to its environment or operations and responds by implementing appropriate safeguards in a timely fashion.^[489]

We also propose to delete the requirement that the evaluation be performed “based initially on the standards implemented under this rule” because an evaluation is performed to assess the effect(s) of a planned change on the environment, which can be observed when those effects are compared to the environment reflected in the risk analysis. Additionally, the Department proposes to add two implementation specifications at ( print page 942) proposed 45 CFR 164.308(a)(3)(ii). The proposed implementation specification for performance at proposed 45 CFR 164.308(a)(3)(ii)(A) would require that a regulated entity conduct the evaluation within a reasonable period of time before making a change to its environment or operations, while the proposed implementation specification for response at proposed 45 CFR 164.308(a)(3)(ii)(B) would require a regulated entity to respond to the evaluation in accordance with its risk management plan.

A change in the regulated entity's environment or operations would include, but would not be limited to, the adoption of new technology assets; the upgrading, updating, or patching of technology assets; newly recognized threats to the confidentiality, integrity, or availability of ePHI; a sale, transfer, merger or consolidation of all or part of the regulated entity with another person; a security incident that affects the confidentiality, integrity, or availability of ePHI; and relevant changes in Federal, State, Tribal, and territorial law.

NIST guidance provides descriptions of key activities and sample questions that would help regulated entities meet this evaluation standard.^[490] They include:

• Determine whether internal or external evaluation is most appropriate. Which staff has the technical experience and expertise to evaluate the systems? If an outside vendor is used, what factors should be considered when selecting the vendor, such as credentials and experience?
• Develop standards and measurements for reviewing all standards and implementation specifications of the Security Rule. Have management, operational, and technical issues been considered? Do the elements of each evaluation procedure (e.g., questions, statements, or other components) address individual, measurable security safeguards for ePHI?
• Conduct an evaluation. Has the process been formally communicated to those who have been assigned roles and responsibilities in the evaluation process? Has the organization explored the use of automated tools to support the process?
• Document results, including: each evaluation finding and remediation options, recommendations, and decisions; known gaps between identified risks, mitigating security controls, and any acceptance of risk, including justification; developed security program priorities and established targets for continuous improvement; use of evaluation results to inform security changes to protect ePHI; communication of evaluation results, metrics, and/or measurements to relevant organizational personnel.
• Repeat evaluations periodically. Establish the frequency of evaluations, repeating evaluations when environmental and operational changes that affect the security of ePHI are made (e.g., if new technology is adopted or if there are newly recognized risks to the confidentiality, integrity, or availability of ePHI).

Despite the existing standard and the availability of guidance, many regulated entities do not evaluate how changes in their environment, such as a merger or acquisition or implementation of new technology, may affect the security of ePHI. In some instances, regulated entities assert that they have done so, but have no documentation of the purported evaluation. The Department believes that this proposal, if adopted, would clarify our expectations for implementing these safeguards.

f. Section 164.308(a)(4)(i)—Standard: Patch Management

As described in Department guidance, regulated entities can defend themselves from common cyberattacks, but hackers continue to target the health care industry in search of ways to access valuable ePHI.^[491] Accordingly, timely implementation of patches for known vulnerabilities is crucial to maintaining the security of ePHI. Many cyberattacks could be prevented or substantially mitigated if regulated entities implemented activities to manage the implementation of patches, updates, and upgrades to comply with the Security Rule's requirements for risk management, which can deter one of the common types of attacks: exploitation of known vulnerabilities. If an attack is successful, the intruder often will encrypt a regulated entity's ePHI to hold it for ransom, or exfiltrate the data for future purposes including identity theft or blackmail. Cyberattacks are especially concerning in the health care sector because they can disrupt the provision of health care services. Exploitable vulnerabilities can exist in many parts of a regulated entity's information systems, but often, known vulnerabilities can be mitigated by applying vendor patches, updating software or system configurations, or upgrading to a newer version of the product. If a patch, update, or upgrade is unavailable, vendors often suggest actions to take, that is, compensating controls, to mitigate a newly discovered vulnerability. Such actions could include modifications of configuration files or disabling of affected services. Regulated entities should pay careful attention to cybersecurity alerts describing newly discovered vulnerabilities. These alerts often include information on mitigation activities and patching.

Risk management processes that are compliant with the Security Rule include identifying and mitigating risks and vulnerabilities that unpatched software poses to an organization's ePHI. Mitigation activities could include installing patches if patches are available and patching is reasonable and appropriate. In situations where patches are not available ( e.g., obsolete or unsupported software) or testing or other concerns weigh against patching as a mitigation solution,^[492] regulated entities should implement reasonable compensating controls to reduce the risk of identified vulnerabilities to a reasonable and appropriate level ( e.g., restricting network access or disabling network services to reduce vulnerabilities that could be exploited via network access). Security vulnerabilities may be present in many types of software, including databases, EHRs, operating systems, email, and device firmware. Each type of program would have its own unique set of vulnerabilities and challenges for applying patches, but identifying and mitigating the risks unpatched software ( print page 943) poses to ePHI is important to ensuring that ePHI is protected.^[493]

Although older applications or devices may no longer be supported with patches for new vulnerabilities, regulated entities must still take appropriate action if a newly discovered vulnerability affects an older application or device. If an obsolete, unsupported system cannot be upgraded or replaced, additional safeguards should be implemented or existing safeguards enhanced to mitigate known vulnerabilities until upgrade or replacement can occur ( e.g., increase access restrictions, remove or restrict network access, disable unnecessary features or services).^[494]

Patches can be applied to software and firmware on all types of devices—telephones, computers, servers, routers, and more. Installation of vendor-recommended patches is typically a routine process. However, regulated entities should be prepared if issues arise as a result of applying patches. Software and hardware are often interconnected and dependent on the functionality and output of other information systems or components of other information systems. When certain changes are made, including the installation of a patch, software dependent on the changed application may not perform as expected because settings or data may be affected. Thus, in complex environments, patch management plays a crucial role in the safe and correct implementation of these changes.^[495] Enterprise patch management is the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.^[496] NIST has issued a series of guidance documents that regulated entities can use to design their own patch management processes as part of their risk management plans.

Consistent with previously issued guidance, the discussion above, and recommendations from NCVHS,^[497] the Department proposes a new standard for patch management at proposed 45 CFR 164.308(a)(4)(i) that would require a regulated entity to implement written policies and procedures for applying patches and updating the configurations of its relevant electronic information systems. This proposed standard would ensure that a regulated entity is aware of its liability for appropriately safeguarding ePHI by installing patches, updates, and upgrades throughout its relevant electronic information systems.

The Department proposes six implementation specifications at proposed 45 CFR 164.308(a)(4)(ii) that would be associated with the proposed standard for patch management. The proposed implementation specification for policies and procedures at proposed paragraph (a)(4)(ii)(A) would require a regulated entity to establish written policies and procedures for identifying, prioritizing, acquiring, installing, evaluating, and verifying the timely installation of patches, updates, and upgrades throughout its electronic information systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI. Under the proposed implementation specification for maintenance at proposed paragraph (a)(4)(ii)(B), a regulated entity would be required to review its patch management written policies and procedures at least once every 12 months and modify them as reasonable and appropriate based on that review. The proposed implementation specification for application at proposed paragraph (a)(4)(ii)(C) would require a regulated entity to patch, update, and upgrade the configurations of its relevant electronic information systems in accordance with its written policies and procedures and based on the results of: the regulated entity's risk analysis that would be required by proposed 45 CFR 164.308(a)(2), the vulnerability scans that would be required under proposed 45 CFR 164.312(h)(2)(i), the monitoring of authoritative sources that would be required under proposed 45 CFR 164.312(h)(2)(ii), and penetration tests proposed at 45 CFR 164.312(h)(2)(iii). The proposal would require that such actions be taken within a reasonable and appropriate period of time, except to the extent that an exception in proposed paragraph (h)(2)(ii)(D) applies. Specifically, a reasonable and appropriate period of time to patch, update, or upgrade the configuration of a relevant electronic information system would be within 15 calendar days of identifying the need to address a critical risk where a patch, update, or upgrade is available; or, where a patch, update, or upgrade is not available, within 15 calendar days of a patch, update, or upgrade becoming available. The proposal would require that, within 30 calendar days of identifying the need to address a high risk,^[498] a regulated entity patch, update, or upgrade the configuration of a relevant electronic information system where a patch, update, or upgrade is available; or, where a patch, update, or upgrade is not available, within 30 calendar days of a patch, update, or upgrade becoming available. For all other patches, updates, or upgrades to the configurations of relevant electronic information systems, a reasonable and appropriate period of time would be determined by the regulated entity's written policies and procedures for identifying, prioritizing, acquiring, installing, evaluating, and verifying the timely installation of patches, updates, and upgrades.

For the proposed exceptions to apply, we propose in proposed paragraph (a)(4)(ii)(D) that a regulated entity would be required to document that an exception applies and that all other applicable conditions are met. The first proposed exception in proposed 45 CFR 164.308(a)(4)(ii)(D)( 1) would be for when a patch, update, or upgrade to the configuration of a relevant electronic information system is not available to address a risk identified in the regulated entity's risk analysis. The second proposed exception would be in proposed 45 CFR 164.308(a)(4)(ii)(D)( 2) for when the only available patch, update, or upgrade would adversely affect the confidentiality, integrity, or availability of ePHI. The Department anticipates that this proposed exception would apply when a regulated entity tests a patch, update, or upgrade and determines that it would adversely affect the confidentiality, integrity, or availability of ePHI or where there are reports from government sources or persons with appropriate knowledge of an experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of ePHI indicating that the patch, update, or ( print page 944) upgrade is likely to adversely affect the confidentiality, integrity, or availability of ePHI.

In proposed paragraph (a)(4)(ii)(E), the Department proposes to require a regulated entity document in real-time the existence of the applicable exception and to implement reasonable and appropriate compensating controls. Similarly, in proposed paragraph (a)(4)(ii)(F), we propose that, where an exception applies, a regulated entity would be required to implement reasonable and appropriate security measures as compensating controls to address the identified risk according to the timeliness requirements in proposed 45 CFR 164.308(a)(5)(ii)(D) until such time as a patch, update, or upgrade that does not adversely affect the confidentiality, integrity, or availability of ePHI becomes available.

This proposed standard aligns with the Department's enhanced CPG for Cybersecurity Mitigation by quickly requiring a regulated entity to prioritize and mitigate vulnerabilities discovered by vulnerability scanning and penetration testing.^[499]

g. Section 164.308(a)(5)(i)—Standard: Risk Management

The Department proposes to elevate the implementation specification for risk management to a standard at proposed 45 CFR 164.308(a)(5)(i). This proposed standard would require a regulated entity to establish and implement a plan for reducing the risks identified through its risk analysis activities. Specifically, it would require a regulated entity to implement security measures sufficient to reduce risks and vulnerabilities to all ePHI to a reasonable and appropriate level. What would constitute a reasonable and appropriate level depends on the regulated entity's specific circumstances, including but not limited to its size, needs and capabilities, risk profile, the ability of security measures to reduce or eliminate a particular identified risk or vulnerability, and the ubiquity of such security measures. We also propose four implementation specifications that would require regulated entities to engage in activities that are consistent with previously issued guidance described below.

Under the proposed implementation specification for planning at proposed paragraph (a)(5)(ii)(A), a regulated entity would be required to establish and implement a written risk management plan for reducing risks to all ePHI, including, but not limited to, those risks identified by the regulated entity's risk analysis,^[500] to a reasonable and appropriate level. Proposed paragraph (a)(5)(i)(B) contains the proposed implementation specification for maintenance and would require the regulated entity to review the written risk management plan at least once every 12 months, and as reasonable and appropriate in response to changes in its risk analysis. The Department would interpret “reasonable and appropriate” in both paragraphs as requiring the regulated entity to take into account not only its specific circumstances, but also the criticality of the risks identified. We propose an implementation specification for priorities at proposed 45 CFR 164.308(a)(5)(ii)(C) that would require a regulated entity's written risk management plan to prioritize the risks identified in the regulated entity's risk analysis based on the risk levels determined by that analysis. Finally, in the proposed implementation specification for implementation at proposed 45 CFR 164.308(a)(5)(ii)(D), we propose to require that a regulated entity implement security measures in a timely manner to address the risks identified in the regulated entity's risk analysis in accordance with the priorities established under paragraph (a)(5)(ii)(C). The proposed risk management standard aligns with the Department's essential CPG to Mitigate Known Vulnerabilities.^[501]

The Department previously issued guidance on risk management, including links to NIST resources, that is consistent with what we propose in this NPRM.^[502] We encourage regulated entities to refer to similar NIST guidance for descriptions of risk management activities.^[503] The results of a risk analysis, performed in accordance with the proposed standard for risk analysis, generally provide the regulated entity with a list of applicable “threat/vulnerability pairs” as well as the overall “risk rating” of each pair to the confidentiality, integrity, and availability of ePHI.^[504] For example, some threat/vulnerability pairs may result in a risk rating of moderate or high level of risk to ePHI, while other pairs may result in a risk rating of low level of risk. The regulated entity would need to determine what risk rating poses an unacceptable level of risk to ePHI and address any threat/vulnerability pairs that indicate a risk rating above the organization's risk tolerance.^[505]

Under this proposed standard, the regulated entity would be required to reduce the risks to its ePHI to a level that is reasonable and appropriate for its specific circumstances. Ultimately, the regulated entity's risk assessment processes should inform its decisions about the manner in which it will implement security measures to comply with the Security Rule's standards and implementation specifications.^[506] Additionally, each regulated entity would be required to document the security controls it has implemented because it has determined them to be reasonable and appropriate, including analyses, decisions, and the rationale for decisions made to refine or adjust the security controls.^[507]

As stated by NIST, “the documentation and retention of risk assessment and risk management activities” is “important for future risk management efforts.” ^[508] In general, risk management activities “should be performed with regular frequency to examine past decisions, reevaluate risk likelihood and impact levels, and assess the effectiveness of past remediation efforts.” ^[509] Risk management plans should address risk appetite, risk tolerance, workforce duties, responsible parties, the frequency of risk management, and required documentation.^[510]

h. Section 164.308(a)(6)(i)—Standard: Sanction Policy

Consistent with other proposals to elevate certain critical implementation specifications to standards, we propose to elevate the implementation specification for sanction policy at 45 CFR 164.308(a)(ii)(C) to a standard for sanction policy at proposed 45 CFR 164.308(a)(6)(i). We propose this standard because applying appropriate sanctions against workforce members who fail to comply with security requirements, and thus imperil the ( print page 945) security of ePHI, serves as an important tool for improving compliance by other workforce members with the regulated entity's safeguards for ePHI. While the Department does not propose to modify the language of the standard, we are proposing three implementation specifications that are consistent with guidance that was previously issued by the Department.

Specifically, under the proposed implementation specification for policies and procedures at proposed 45 CFR 164.308(a)(6)(ii)(A), a regulated entity would be required to establish written policies and procedures for sanctioning workforce members who fail to comply with the regulated entity's security policies and procedures. The proposed implementation specification for modifications at paragraph (a)(6)(ii)(B) would require a regulated entity to review its written sanctions policies and procedures at least once every 12 months, and, based on that review, modify such policies and procedures as reasonable and appropriate. The proposed implementation specification for application at proposed paragraph (a)(6)(ii)(C) would direct a regulated entity to apply appropriate sanctions against workforce members who fail to comply with such security policies and procedures and to document when it sanctions a workforce member and the circumstances in which it applies such sanctions.

The policy choices represented in this NPRM are informed by the compliance challenges OCR has observed through its enforcement activities. These challenges demonstrate that regulated entities would benefit from greater precision and clarity about their legal obligations in the proposed standard. Additionally, according to a recent survey of IT and IT security practitioners in healthcare, careless users were the top cause of data loss and exfiltration, while accidental loss was the second highest cause. Thirty-one percent of respondents indicated that the data loss or exfiltration was caused by a failure of workforce members to follow organizational policies.^[511] As described in existing Department guidance, an organization's sanction policies can be an important tool for supporting accountability and improving cybersecurity and data protection.^[512] Sanction policies can be used to address the intentional actions of malicious insiders, such as a workforce member that accesses the ePHI of a public figure or steals ePHI to sell as part of an identity-theft ring, as well as the failure of workforce members to comply with policies and procedures, such as failing to secure data on a network server or investigate a potential security incident.

Sanction policies that are appropriately applied can improve a regulated entity's general compliance with the HIPAA Rules. Imposing consequences on workforce members who violate a regulated entity's policies and procedures implemented as required by the Security Rule or the HIPAA Rules generally can be effective in creating a culture of HIPAA compliance and improved cybersecurity. Knowledge that there is a negative consequence to noncompliance enhances the likelihood of compliance.^[513] Training workforce members on a regulated entity's sanction policy can also promote compliance and greater cybersecurity vigilance by informing workforce members in advance which actions are prohibited and punishable.^[514] A sanction policy that clearly communicates a regulated entity's expectations should ensure that workforce members understand their individual compliance obligations and consequences of noncompliance.

Regulated entities have the flexibility to implement the standard in a manner consistent with numerous factors, including but not limited to their size, degree of risk, and environment. The HIPAA Rules do not require regulated entities to impose any specific penalty for any particular violation, nor do they require regulated entities to implement any particular methodology for sanctioning workforce members. Rather, in any particular case, each regulated entity must determine the type, cause, and severity of sanctions imposed based upon its policies and the relative severity of the violation.^[515] A regulated entity may structure its sanction policies in the manner most suitable to its organization. As described in previously issued guidance materials from the Department and NIST, regulated entities should consider the following when drafting or revising their sanction policies:

• Documenting or implementing sanction policies pursuant to a formal process.^[516]

• Requiring workforce members to affirmatively acknowledge that a violation of the organization's HIPAA policies or procedures may result in sanctions.^[517]

• Documenting the sanction process, including the personnel involved, the procedural steps, the time-period, the reason for the sanction(s), and the final outcome of an investigation.^[518]

• Creating sanctions that are “appropriate to the nature of the violation.” ^[519]

• Creating sanctions that “vary depending on factors such as the severity of the violation, whether the violation was intentional or unintentional, and whether the violation indicated a pattern or practice of improper use or disclosure of [PHI].” ^[520]

• Creating sanctions that “range from a warning to termination.” ^[521]

• Providing examples “of potential violations of policy and procedures.” ^[522]

Generally, it is important for a regulated entity to consider whether its sanction policies align with its general disciplinary policies, and how the individuals or departments involved in the sanction processes can work in concert, when appropriate. Regulated entities may also want to consider how sanction policies can be fairly and consistently applied throughout the organization, to all workforce members, including management.^[523] The deterrent effect of penalizing noncompliance and misconduct paired with clear communications about the consequences of noncompliance can promote greater compliance with the HIPAA Rules through accountability, understanding, and transparency.

( print page 946)

i. Section 164.308(a)(7)(i)—Standard: Information System Activity Review

As described in previously issued HHS guidance, review of activity in its relevant electronic information systems and their components, including workstations,^[524] enables a regulated entity to determine if any ePHI has been used or disclosed in an inappropriate manner.^[525] The procedures should be customized to meet the regulated entity's risk management strategy and consider the capabilities of all information systems with ePHI.^[526] These activities should also promote continual awareness of any information system activity that could suggest a security incident.^[527]

Detecting and preventing data leakage initiated by malicious authorized users is a significant challenge.^[528] Identifying potential malicious activity in relevant electronic information systems, including in workstations and other components, as soon as possible is key to preventing or mitigating the impact of such activity.^[529] To identify potential suspicious activity, organizations should consider an insider's interactions with information systems and their components. A regulated entity can detect anomalous user behavior or indicators of misuse by either a trusted employee or third-party vendor who has access to critical systems, workstations and other system components, and data.^[530] To minimize this risk, an organization may employ safeguards that detect suspicious user activities, such as traffic to an unauthorized website, downloading data to an external device ( e.g., thumb drive), or access to a network server by an unauthorized mobile device. Maintaining audit controls ( e.g., system event logs, application audit logs) and regularly reviewing audit logs, access reports, and security incident tracking reports are important security measures that can assist in detecting and identifying suspicious activity or unusual patterns of data access.^[531]

Regulated entities should regularly review activity in their relevant electronic information systems (including the components of such systems) for potential concerns and consider ways to automate such reviews.^[532] Additionally, regulated entities are responsible for establishing and implementing appropriate standard operating procedures, including determining the types of audit trail data and monitoring procedures that would be needed to derive exception reports.^[533] They also must activate the necessary review processes and maintain auditing and logging activity.^[534]

Department and NIST guidance advise regulated entities to consider many questions when establishing their policies and procedures for reviewing activity in their relevant electronic information systems review.^[535] These include:

• What logs or reports are generated by the information systems?
• Is there a policy that establishes what reviews will be conducted?
• Are there corresponding procedures that describe the specifics of the reviews?
• Who is responsible for the overall process and results?
• How often will review results be analyzed?
• Where will audit information reside (e.g., separate server)? Will it be stored external to the organization ( e.g., cloud service provider)?

Compliance challenges observed through OCR's enforcement activities suggest that regulated entities would benefit from an expanded standard to provide more details on compliance expectations. Investigations of reported breaches of unsecured PHI discussed above as examples of risk analysis failures also identified a potential failure by the regulated entities to conduct appropriate information system activity review.^[536] In an investigation involving a large health care provider, the ePHI of more than 12,000 patients was sold to an identity theft ring by employees who, for six months, inappropriately accessed patient account information.^[537] Compliance with the requirement to implement procedures to regularly review records of activity in relevant electronic information systems, such as audit logs, access reports, and security incident tracking, could have identified and mitigated these disclosures.^[538]

Similarly, a business associate experienced an intrusion into its systems that it failed to notice for over 20 months. Eventually, the ePHI of more than 200,000 individuals associated with several covered entities was encrypted in a ransomware cyberattack.^[539] Among other factors, OCR's investigation indicated that the business associate potentially failed to implement procedures for regularly reviewing records of activity in its relevant electronic information system, such as audit logs, access reports, and security incident tracking reports.^[540]

Consistent with previously issued guidance and based on OCR's enforcement experience, the Department proposes to elevate the existing implementation specification for information system activity review to a standard and to redesignate it as proposed 45 CFR 164.308(a)(7)(i). The purpose of the proposal is to impose specific requirements on a regulated entity to review the activity occurring in its relevant electronic information systems, including the activity occurring in the components of such systems. By virtue of these proposed requirements, we would specify actions that a regulated entity is required to take to ensure that only appropriate users access ePHI and that it responds quickly to any suspicious activity in its relevant electronic information systems, including in components thereof, such as workstations that connect to or otherwise access its relevant electronic information systems. We also propose to revise the language to provide regulated entities with additional direction regarding their review of suspicious activities. The proposed standard, if adopted, would require a regulated entity to implement written policies and procedures for regularly reviewing ( print page 947) records of activity in its relevant electronic information systems.

The Department proposes five implementation specifications for the proposed standard for information system activity review. The proposed implementation specification for policies and procedures at proposed 45 CFR 164.308(a)(7)(ii)(A) would require a regulated entity to establish written policies and procedures for retaining and reviewing records of activity in the regulated entity's relevant electronic information systems by persons and technology assets. Such written policies and procedures should require review of activity in the regulated entity's relevant electronic information systems as a whole, as well as the system's components, including but not limited to any workstations. They should also include information on the frequency for reviewing such records. The frequency of review may vary based on the specific type of record being reviewed and the information it contains. According to the proposed implementation specification for scope at proposed 45 CFR 164.308(a)(7)(ii)(B), records of activity in the regulated entity's relevant electronic information systems by persons and technology assets would include, but would not be limited to, audit trails, event logs, firewall logs, system logs, data backup logs, access reports, anti-malware logs, and security incident tracking reports. The proposed implementation specification for records review at proposed 45 CFR 164.308(a)(7)(ii)(C) would require a regulated entity to review records of activity in its relevant electronic information systems by persons and technology assets as often as reasonable and appropriate for the type of report or log. They would also be required to document such review. A proposed implementation specification for record retention at proposed 45 CFR 164.308(a)(7)(ii)(D) would require a regulated entity to retain records of activity in its relevant electronic information systems by persons and technology assets. Under the proposal, the regulated entity would be required to retain such records for an amount of time that is reasonable and appropriate for the specific type of report or log. For example, it may be reasonable and appropriate to retain audit trails for a different amount of time than security incident tracking reports because of the type of information they contain and their purpose. The proposed implementation specification for response at proposed 45 CFR 164.308(a)(7)(ii)(E) would require a regulated entity to respond to a suspected or known security incident identified during the review of activity in its relevant electronic information systems, including any components thereof, such as workstations, in accordance with the regulated entity's security incident plan.^[541] Finally, the proposed implementation specification for maintenance at proposed 45 CFR 164.308(a)(7)(ii)(F) would require a regulated entity to review and test its written policies and procedures for reviewing activity in its relevant electronic information systems at least once every 12 months. The regulated entity would be expected to modify such policies and procedures as reasonable and appropriate, based on the results of that review.

Consider a large regulated entity that may have thousands of workforce members accessing various networks and relevant electronic information systems, generating large amounts of log and audit data. Given the size, complexity, and capabilities of entities of such size, a reasonable and appropriate process for reviewing activity may include the adoption of an automated solution that performs rules-based enterprise log aggregation and analysis to identify anomalous or suspicious patterns of behavior in the regulated entity's relevant electronic information systems and the components thereof, including but not limited to workstations, in real-time and sends alerts of potential security incidents to a workforce member or team for further review and action. By contrast, for a small regulated entity, it might be reasonable and appropriate to have designated staff that manually review log files and audit trails multiple times per week.

j. Section 164.308(a)(8)—Standard: Assigned Security Responsibility

The Department proposes to redesignate the standard for assigned security responsibility at 45 CFR 164.308(a)(2) as proposed 45 CFR 164.308(a)(8). OCR's enforcement experience demonstrates that, in practice, many regulated entities follow informal policies and procedures that are not documented, and have not documented the identification of the Security Official in writing.

Based on OCR's enforcement experience, and consistent with existing guidance, we propose to modify the standard to specify that a regulated entity must identify in writing the Security Official who is responsible for the establishment and implementation of the policies and procedures, whether written or otherwise, and deployment of technical controls. These proposals are consistent with our general intention in this NPRM to propose to clarify that policies and procedures required by the Security Rule should be reduced to writing and to distinguish between the implementation of written policies and procedures and the deployment of technical controls.

As we previously explained in guidance,^[542] the purpose of this standard is to identify who would be operationally responsible for assuring that the regulated entity complies with the Security Rule. It is comparable to the Privacy Rule standard for personnel designations at 45 CFR 164.530(a)(1), which requires all covered entities to designate a Privacy Official. The Security Official and Privacy Official can, but need not be, the same person. While one workforce member must be designated as having overall responsibility, other workforce members may be assigned specific security responsibilities ( e.g., facility security, network security). When making this decision, regulated entities should consider basic questions, such as: Has the organization agreed upon, and clearly identified and documented, the responsibilities of the Security Official? How are the roles and responsibilities of the Security Official crafted to reflect the size, complexity, and technical capabilities of the organization?

NIST guidance urges the regulated entity to select a workforce member who is able to assess the effectiveness of security to serve as the point of contact for security policy, implementation, and monitoring.^[543] It further recommends that a regulated entity should document the responsibilities in a job description and communicate this assigned role to the entire organization. NIST provides additional sample items for consideration by a regulated entity organizing its security practices, including identifying the workforce members in the organization who oversee the development and communication of security policies and procedures, direct IT security purchasing and investment, and ensure that security concerns have been addressed in system implementation. NIST also offers that a regulated entity should ask whether the security official has adequate access and communications with senior officials in the organization and whether there is a ( print page 948) complete job description that accurately reflects assigned security duties and responsibilities.

k. Section 164.308(a)(9)(i)—Standard: Workforce Security

The purpose of the workforce security standard is to ensure that workforce members only have access to ePHI that they need to perform their assigned functions and are prevented from accessing ePHI that they are not authorized to access to perform such functions. The proposed changes to the standard and implementation specifications would clarify the actions required of a regulated entity to assure such limits.

Individuals have been harmed in the past by the failure of regulated entities to comply with the Security Rule requirements for workforce security. For example, a former employee of a large covered entity was able to access their former worksite and workstation using still-active credentials for more than a week after their employment was terminated.^[544] OCR's investigation found evidence of a potential failure to terminate the former employee's access to PHI, which enabled the former employee to download the ePHI of nearly 500 individuals, including their names, addresses, dates of birth, race/ethnicity, gender, and sexually transmitted infection test results onto a USB drive. This type of real-world experience and OCR's observations more broadly inform the changes proposed in this NPRM.

Moreover, this proposal is consistent with guidance issued by HHS and NIST for implementing this standard and associated implementation specifications. For example, in guidance issued in 2005, we explained that regulated entities must identify workforce members who need access to ePHI to carry out their duties.^[545] For each workforce member or job function, the regulated entity must identify the ePHI that is needed, when it is needed, and make reasonable efforts to control access to the ePHI, a concept generally referred to as role-based access ( i.e., authorizing access to ePHI only when such access is appropriate based on the workforce member's role).^[546] This also includes identification of the computer systems and applications that provide access to the ePHI. A regulated entity must provide only the minimum necessary access to ePHI that is required for a workforce member to do their job.^[547] As described in HHS guidance, access authorization is the process of determining whether a particular user (or a computer system) has the right, consistent with their function, to carry out a certain activity, such as reading a file or running a program.^[548] Implementation may vary among regulated entities, depending on the size and complexity of their workforce, and their electronic information systems that contain ePHI. For example, in a small medical practice, all staff members may need to access all ePHI in their information systems because each staff member may perform multiple functions. In this case, the regulated entity would document the reasons for implementing policies and procedures that permit this type of global access. If the documented rationale is reasonable and appropriate, this may be an acceptable approach. The implementation specification provision for authorization and/or supervision provides the necessary checks and balances to ensure that all members of the workforce have appropriate access (or, in some cases, no access) to ePHI.

NIST guidance provides descriptions of key activities and sample questions for regulated entities implementing this implementation specification.^[549] To implement procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it might be accessed, the guidance advises regulated entities to consider whether chains of command and lines of authority have been established, as well as the identity and roles of supervisors. A regulated entity also should establish clear job descriptions and responsibilities, which includes defining roles and responsibilities for all job functions; assigning appropriate levels of security oversight, training, and access; and identifying in writing who has the business need and who has been granted permission to view, alter, retrieve, and store ePHI and at what times, under what circumstances, and for what purposes.^[550] To determine the most reasonable and appropriate authorization and/or supervision procedures, a regulated entity must be able to answer some basic questions about existing policies and procedures. For example, are detailed job descriptions used to determine what level of access the person holding the position should have to ePHI? Who has or should have the authority to determine who can access ePHI, e.g., supervisors or managers? Are there written job descriptions that are correlated with appropriate levels of access to ePHI? Are these job descriptions reviewed and updated on a regular basis? Have workforce members been provided copies of their job descriptions and informed of the access granted to them, as well as the conditions by which this access can be used? As noted above, a smaller regulated entity may address compliance by implementing a simpler approach, but it is still liable for ensuring that workforce members only have access to ePHI that they need to perform their assigned functions.^[551]

NIST also recommends establishing criteria and procedures for hiring and assigning tasks and ensuring that these requirements are included as part of the personnel hiring process.^[552] In its guidance, NIST provides questions and suggestions for regulated entities to consider with respect to these criteria, procedures, and requirements. NIST guidance also describes this implementation specification as calling for regulated entities to implement appropriate screening of persons who would have access to ePHI, and a procedure for obtaining clearance from appropriate offices or workforce members where access is provided or terminated.^[553] Similarly, the Department's guidance on workforce clearance procedures states that the clearance process must establish the procedures to verify that a workforce member would in fact have the appropriate access for their job function.^[554] A regulated entity may choose to perform this type of screening procedure separate from, or as a part of, the authorization and/or supervision procedure. Sample questions for ( print page 949) regulated entities to consider include the following: Are there existing procedures for determining that the appropriate workforce members have access to the necessary information? Are the procedures used consistently within the organization when determining access of related workforce job functions? NIST guidance describes this implementation specification as calling for regulated entities to implement appropriate screening of persons who would have access to ePHI, and a procedure for obtaining clearance from appropriate offices or workforce members where access is provided or terminated.^[555]

We issued guidance in 2017 addressing termination procedures.^[556] Data breaches caused by current and former workforce members are a recurring issue across many industries, including the health care industry. Effective identity and access management policies and controls are essential to reduce the risks posed by these types of insider threats. Identity and access management can include many processes, but, most commonly, it would include the processes by which appropriate access to data is granted and terminated by creating and managing user accounts. Ensuring that user accounts are terminated—and in a timely manner—so that former workforce members do not have access to data, is one important way identity and access management can help reduce risks posed by insider threats. Additionally, effective termination procedures also reduce the risk that inactive user accounts ( e.g., user accounts that are not being used or are inactive but are not fully terminated or disabled) could be used by a current or former workforce member with malicious motives to get access to ePHI. The Department's guidance also offers tips to prevent unauthorized access to PHI by former workforce members, such as having standard procedures of all action items to be completed when an individual leaves.^[557]

Guidance that we issued in 2019 further explains that “security is a dynamic process.” ^[558] Good security practices entail continuous awareness, assessment, and action in the face of changing circumstances. The information users can and should be allowed to access may change over time; organizations should recognize this in their policies and procedures and in their implementation of those policies and procedures. For example, if a user is promoted, demoted, or transfers to a different department, a user's need to access data may change. In such situations, the user's data access privileges should be re-evaluated and, as needed, modified to match the new role, if needed.^[559] As described in other HHS guidance, these procedures should also address the complexity of the organization and the sophistication of its relevant electronic information systems.^[560]

NIST guidance provides additional descriptions of key activities and sample questions for regulated entities to consider when implementing this standard and associated implementation specifications.^[561] Regulated entities should establish a standard set of procedures that should be followed to recover access control devices ( e.g., identification badges, keys, access cards) when employment ends and, likewise, they should timely deactivate computer access ( e.g., disable user IDs and passwords) and facility access ( e.g., change facility security codes/PINs). Sample questions for implementation include the following: Are there separate procedures for voluntary termination ( e.g., retirement, promotion, transfer, change of employment) versus involuntary termination ( e.g., termination for cause, reduction in force, involuntary transfer, criminal or disciplinary actions)? Is there a standard checklist for all action items that should be completed when a workforce member leaves ( e.g., return of all access devices, deactivation of accounts, and delivery of any needed data solely under the workforce member's control)? Do other organizations need to be notified to deactivate accounts to which that the workforce member had access in the performance of their employment duties?

However, regulated entities often do not establish or implement written procedures, nor, even in instances where they have established or implemented them, have they done so in an appropriate fashion to protect ePHI from improper access by current or former workforce members.

Consistent with the guidance described above and other proposals in this NPRM, the Department proposes to redesignate the workforce security standard at 45 CFR 164.308(a)(3)(i) as proposed 45 CFR 164.308(a)(9)(i), to add a paragraph heading to clarify the organization of the regulatory text, and to modify the regulatory text clarify that a regulated entity must implement written policies and procedures ensuring that workforce members have appropriate access to ePHI and to relevant electronic information systems. The regulated entity must also implement written policies and procedures preventing workforce members from accessing ePHI and relevant electronic information systems if they are not authorized to do so. The modifications we propose to the implementation specification for authorization and/or supervision would clarify that a regulated entity is required to establish and implement written procedures for the authorization and/or supervision of workforce members who access ePHI or relevant electronic information systems or who work in facilities where ePHI or relevant electronic information systems might be accessed.^[562] We propose similar modifications to the implementation specification for workforce clearance procedure, which would require a regulated entity to establish and implement written procedures to determine that the access of a workforce member to ePHI or relevant electronic information systems is appropriate, in accordance with written policies and procedures for granting and revising access to ePHI and relevant electronic information systems as required by proposed 45 CFR 164.308(a)(10)(ii)(B).^[563] Additionally, we propose several clarifications to the implementation specification for termination procedures. Specifically, the proposed implementation specification for modification and termination procedures at proposed 45 CFR 164.308(a)(9)(ii)(C) would require procedures for terminating a workforce member's access to ePHI and relevant electronic information systems, and to facilities where ePHI or relevant electronic information systems might be accessed. Proposed paragraph (a)(9)(ii)(C)( 1) would require a regulated entity to establish and implement written procedures for terminating a workforce member's access to ePHI and relevant electronic information systems, ( print page 950) and to locations where ePHI or relevant electronic information systems might be accessed. Proposed paragraph (a)(9)(ii)(C)( 2) would require that the workforce member's access be terminated as soon as possible, but no later than one hour after the workforce member's employment or other arrangement ends. A proposed implementation specification for notification at proposed 45 CFR 164.308(a)(9)(ii)(D) would require a regulated entity to establish and implement written procedures for notifying another regulated entity of a change in, or termination of, a workforce member's authorization to access ePHI or relevant electronic information systems. Proposed paragraph (a)(9)(ii)(D)( 1) would require the regulated entity to establish and implement written procedures for notifying another regulated entity after a change in or termination of a workforce member's authorization to access ePHI or relevant electronic information systems that are maintained by such other regulated entity where the workforce member is or was authorized to access such ePHI or relevant electronic information systems by the regulated entity making the notification. Proposed paragraph (a)(9)(ii)(D)( 2) would require the notice to be provided as soon as possible, but no later than 24 hours after the workforce member's authorization to access ePHI or relevant electronic information systems is changed or terminated. Finally, a proposed new implementation specification for maintenance at proposed 45 CFR 164.308(a)(9)(ii)(E) would require a regulated entity to review and test its written workforce security policies and procedures at least once every 12 months and to modify them as reasonable and appropriate.^[564] The proposed implementation specifications for termination procedures and notification implementation align with the Department's essential CPG for Revoke Credentials for Departing Workforce Members, Including Employees, Contractors, Affiliates, and Volunteers by requiring a regulated entity to promptly remove access following a change in or termination of a user's authorization to access ePHI.^[565]

l. Section 164.308(a)(10)(i)—Standard: Information Access Management

The purpose of the standard for information access management is to protect ePHI by reducing the risk that other persons or technology assets may access the information for their own reasons. Existing HHS guidance explains that restricting access to only those persons and entities with a need for access is a basic tenet of security.^[566] By implementing this standard, the risk of inappropriate disclosure, alteration, or destruction of ePHI is minimized. A regulated entity must determine those persons and technology assets that need access to ePHI within its environment. The implementation specifications associated with the standard on information access management are closely related to those associated with the standard for workforce security.^[567] Compliance with the proposed and existing standards for information access management should support a regulated entity's compliance with the Privacy Rule's minimum necessary requirements, which requires a regulated entity to evaluate its practices and enhance safeguards as needed to limit unnecessary or inappropriate access to and disclosure of PHI.^[568]

OCR's enforcement experience demonstrates that many regulated entities have not adequately implemented this standard. Thus, we believe it is necessary to consider strengthening the requirement. For example, on one occasion, a large covered entity's failure to implement its written policies and procedures to ensure that employees only had access to ePHI that they had proper authorization or authority to access enabled an employee to access the ePHI of more than 24,000 individuals.^[569] This failure also enabled other employees to inappropriately access the ePHI of a celebrity.^[570]

To ensure that regulated entities implement recommendations and best practices for securing ePHI, we propose to require in the standard for information access management and associated implementation specifications that a regulated entity must establish and implement written policies and procedures for authorizing access to ePHI and relevant electronic information systems that are consistent with the Privacy Rule. The Department also proposes to redesignate the standard at 45 CFR 164.308(a)(4)(i) as proposed 45 CFR 164.308(a)(10)(i) and to add a paragraph heading to clarify the organization of the regulatory text. Additionally, the Department proposes to modify three of the associated existing implementation specifications and to add three new implementation specifications as follows.

Specifically, the Department proposes to redesignate the implementation specification for isolating health care clearinghouse functions as proposed 45 CFR 164.308(a)(10)(ii)(A) and to modify it to require a health care clearinghouse that is part of a larger organization to establish and implement written policies and procedures that protect the ePHI and relevant electronic information systems of the clearinghouse from unauthorized access by the larger organization.

The existing implementation specification for isolating health care clearinghouse functions only applies in the situation where a health care clearinghouse is part of a larger organization. This would remain true under the proposal to revise this implementation specification, if adopted. In these situations, the health care clearinghouse is responsible for protecting the ePHI that it is creating, receiving, maintaining, and transmitting. As discussed in NIST guidance, if a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the ePHI of the clearinghouse from unauthorized access by the larger organization.^[571] This necessarily includes its relevant electronic information systems. First, the regulated entity must determine ( print page 951) whether any of its components constitute a health care clearinghouse under the Security Rule.^[572] If no health care clearinghouse functions exist within the organization, the regulated entity should document this finding. If a health care clearinghouse does exist within the organization, the regulated entity must implement procedures that are consistent with the Privacy Rule.^[573] Questions for regulated entities to consider include: If health care clearinghouse functions are performed, are policies and procedures implemented to protect ePHI from the other functions of the larger organization? Does the health care clearinghouse share hardware or software with a larger organization of which it is a part? Does the health care clearinghouse share staff or physical space with staff from a larger organization? Has a separate network or subsystem been established for the health care clearinghouse, if reasonable and appropriate? Has staff of the health care clearinghouse been trained to safeguard ePHI from disclosure to the larger organization, if required for compliance with the Privacy Rule? ^[574] Regulated entities should also consider whether additional technical safeguards are needed to separate ePHI in electronic information systems used by the health care clearinghouse to protect against unauthorized access by the larger organization.

We also propose to redesignate the implementation specification for access authorization as proposed 45 CFR 164.308(a)(10)(ii)(B) and to modify it to emphasize that a regulated entity must establish and implement written policies and procedures for granting and revising access to ePHI and the regulated entity's relevant electronic information systems as necessary and appropriate for each prospective user and technology asset to carry out their assigned function(s) ( i.e., role-based access policies). Additionally, we propose to redesignate the implementation specification for access establishment and modification as 45 CFR 164.308(a)(10)(ii)(D) and to modify the heading to “Access determination and modification.” We also propose to modify this implementation specification to require a regulated entity to establish and implement written policies and procedures that, based on its access authorization policies, establish, document, review, and modify the access of each user and technology asset to specific components of the regulated entity's relevant electronic information systems. Such written policies and procedures would be required to be based upon the regulated entity's policies for authorizing access. Under this proposal, and consistent with the existing implementation specification,^[575] the regulated entity would be required to establish standards for granting access to ePHI and relevant electronic information systems and provide formal authorization from the appropriate authority before granting access to ePHI or relevant electronic information systems. Regulated entities should regularly review personnel access to ePHI and relevant electronic information systems to ensure that access is still authorized and needed, and modify personnel access to ePHI and electronic information systems, as needed, based on review activities.

The existing implementation specification for access authorization calls for the regulated entity to implement policies and procedures for granting access to ePHI, for example, through components of its information system.^[576] The Department's proposal to revise this implementation specification would provide greater specificity than our existing requirements, and echo NIST guidance on this topic. Specifically, NIST guidance ^[577] describes the key steps for developing policies and procedures for granting access to ePHI as follows:

• Decide and document procedures for how access to ePHI would be granted to workforce members within the organization.
• Select the basis for restricting access to ePHI. Select an access control method (e.g., identity-based, role based, or other reasonable and appropriate means of access).
• Decide and document how access to ePHI would be granted for privileged functions.
• Ensure that there is a list of personnel with authority to approve user requests to access ePHI and systems with ePHI.
• Identify authorized users with access to ePHI, including data owners and data custodians.
• Consider whether multiple access control methods are needed to protect ePHI according to the results of the risk assessment.
• Determine whether direct access to ePHI would ever be appropriate for individuals external to the organization (e.g., business partners or patients seeking access to their own ePHI).

Other questions that a regulated entity should consider when establishing such policies and procedures include: Have appropriate authorization and clearance procedures, as specified in the standard for workforce security,^[578] been performed prior to granting access? Do the organization's systems have the capacity to set access controls? Are there additional access control requirements for users who would be accessing privileged functions? Have organizational personnel been explicitly authorized to approve user requests to access ePHI and/or systems with ePHI?

The Department proposes three additional implementation specifications for authentication management, maintenance, and network segmentation. These specifications clarify the Department's expectations for compliance and are consistent with NIST guidance. We believe that the proposed additions would assist regulated entities in their efforts to prevent or mitigate attacks by malicious internal and external actors. For the implementation specification on authentication management at proposed 45 CFR 164.308(a)(10)(ii)(C), we propose to require a regulated entity to establish and implement written policies and procedures for verifying the identities of users and technology assets before accessing the regulated entity's relevant electronic information systems, including written policies and procedures for implementing MFA technical controls.^[579] The proposed implementation specification for network segmentation at proposed 45 CFR 164.308(a)(10)(ii)(E) would require a regulated entity to establish and implement written policies and procedures that ensure that its relevant electronic information systems are segmented to limit access to ePHI to authorized workstations.

Finally, to address the Department's general concerns regarding the ongoing failure of many regulated entities to regularly review and revise their policies and procedures, the proposed implementation specification for maintenance at proposed 45 CFR ( print page 952) 164.308(a)(10)(ii)(F) would require a regulated entity to review the written policies and procedures required by this standard at least once every 12 months and to modify them as reasonable and appropriate.

m. Section 164.308(a)(11)(i)—Standard: Security Awareness Training

A covered entity's workforce is its frontline not only in patient care and patient service, but also in safeguarding the privacy and security of PHI.^[580] The health care sector's risk landscape continues to grow with the increasing number of interconnected, smart devices of all types, the increased use of interconnected medical record and billing systems, and the increased use of applications and cloud computing. This standard reflects the fact that training on data security for workforce members is essential for protecting an organization against cyberattacks.

An organization's training program should be an ongoing, evolving process and flexible enough to educate workforce members on new cybersecurity threats and how to respond to them. As such, regulated entities should consider how often to train workforce members on security issues, given the risks and threats to their enterprises, and how often to send security updates to their workforce members. Many regulated entities have determined that twice-annual training and monthly security updates are necessary, given their risks analyses.

Regulated entities should apply security updates and reminders to quickly communicate new and emerging cybersecurity threats to workforce members such as new social engineering ploys ( e.g., fake tech support requests and new phishing scams) and malicious software attacks including new ransomware variants. Entities need to address what type of training to provide to workforce members on security issues, given the risks and threats to their enterprises. Computer-based training, classroom training, monthly newsletters, posters, email alerts, and team discussions are all tools that different organizations use to fulfill their training requirements. Entities must also address how to document that training to workforce members was provided, including dates and types of training, training materials, and evidence of workforce participation.

HHS has issued many types of training materials on securing PHI.^[581] NIST has also provided detailed guidance for developing and implementing workforce training programs.^[582] Despite this existing guidance, regulated entities often fail to provide appropriate training to adequately safeguard ePHI. For example, in one investigation, OCR investigators found evidence that not only had an ambulance company potentially failed to conduct a risk analysis, it also potentially failed to implement a security training program or to train any of its employees.^[583] Such failures can contribute to breaches of individuals' unsecured ePHI.

To ensure security awareness training compliance, a regulated entity needs to regularly educate its workforce members on the evolving technological threats to ePHI, how to use the technology that the regulated entity has adopted and implemented, and the specific procedures workforce members must follow to ensure that the ePHI remains protected. Additionally, while many educational programs for clinicians provide general training on the HIPAA Rules, the curriculums vary widely. Without providing its own training on the Security Rule, a regulated entity cannot ensure that the training its workforce received elsewhere meets the required standards.

Given the failure of regulated entities to implement the security awareness and training standard and consistent with existing guidance, the Department proposes to provide more detailed requirements for security awareness training. Specifically, the Department proposes to rename and redesignate the standard for security awareness and training at 45 CFR 164.308(a)(5)(i) as the standard for security awareness training at proposed 45 CFR 164.308(a)(11)(i) and to add a paragraph heading to clarify the organization of the regulatory text. The proposed standard would require a regulated entity to implement security awareness training for all workforce members on protection of ePHI and information systems as necessary and appropriate for the members of the workforce to carry out their assigned function(s) ( i.e., role-based training). The proposals to revise this standard would also align with the Department's essential CPG for Basic Cybersecurity Training because they would require a regulated entity to educate users on how to access ePHI and electronic information systems in a manner that protects the confidentiality, integrity, and availability of ePHI.^[584] Additionally, the proposals would align with the essential CPG for Email Security by requiring a regulated entity to train workforce members to guard against, detect, and report suspected or known security incidents, including, but not limited to, malicious software and social engineering.^[585]

We propose four implementation specifications for the proposed security awareness training standard. The proposed implementation specification for training at 45 CFR 164.308(a)(11)(ii)(A) would require a regulated entity to establish and implement security awareness training for all workforce members that addresses the following:

• The written policies and procedures required by the Security Rule, as necessary and appropriate for the workforce members to carry out their assigned functions.^[586]

• Guarding against, detecting, and reporting suspected or known security incidents, including but not limited to malicious software and social engineering.^[587]

• The written policies and procedures for accessing the regulated entity's electronic information systems, including, but not limited to, safeguarding passwords, setting unique passwords of sufficient strength to ensure the confidentiality, integrity, and availability of ePHI, and establishing limitations on sharing passwords. Consistent with the recommendation from NCVHS, such policies and procedures should ensure that the regulated entity does not employ default passwords and should prevent workforce members from sharing of credentials.^[588] We do not propose that passwords be required to meet a particular standard because best practices for password configuration may change over time; however, we believe that it is essential for a regulated ( print page 953) entity to educate its workforce members on best practices for setting passwords and to ensure that its workforce members implement such best practices.

The Department proposes to replace the implementation specification for periodic security updates ^[589] with one addressing the timing and frequency of security awareness training at proposed 45 CFR 164.308(a)(11)(ii)(B). Specifically, we propose to require a regulated entity to provide such training to each member of the regulated entity's workforce by the compliance date for this rulemaking, if finalized, and at least once every 12 months thereafter.^[590] For example, under this proposal, workforce members would receive security awareness training on the protection of ePHI and on the regulated entity's Security Rule policies and procedures that is based on their specific role at least once a year. A regulated entity would be required to provide role-based security awareness training to a new workforce member within a reasonable period of time, but no later than 30 days after the workforce member first has access to the regulated entity's relevant electronic information systems.^[591] We also propose to require that the regulated entity provide such training.^[592] For example, if the entity implements a new EHR system, it would be required to also train its workforce, as appropriate, on measures to guard against security incidents related to the installation, maintenance and/or use of the system.

Additionally, the Department proposes at proposed 45 CFR 164.308(a)(11)(ii)(C) an implementation specification for ongoing education. This would require a regulated entity to provide its workforce members with ongoing reminders of their security responsibilities and notice of relevant threats, including but not limited to, new and emerging malicious software and social engineering. Lastly, we propose a new implementation specification for documentation at proposed 45 CFR 164.308(a)(11)(ii)(D) that would require a regulated entity to document that it has provided training and ongoing reminders to its workforce members.

n. Section 164.308(a)(12)(i)—Standard: Security Incident Procedures

Addressing security incidents is an integral part of an overall security program. While a regulated entity will never be able to prevent all security incidents, implementing the Security Rule standards would reduce the amount and negative consequences of security incidents it encounters. Even regulated entities with detailed security policies and procedures and advanced technology may experience security incidents, but through sufficient planning and continued monitoring generally can mitigate the negative effects of such incidents on regulated entities, and, ultimately, individuals. The security incident procedures standard is intended to help ensure that a regulated entity conducts such planning and monitoring to allow it to mitigate such negative effects.

The Department has also provided guidance that a regulated entity can use to devise its security incident plans. The policies and procedures a regulated entity establishes to prepare for and respond to security incidents can pay dividends with faster recovery times and reduced compromises of ePHI.^[593] A well thought-out, well-tested security incident response plan is integral to ensuring the confidentiality, integrity, and availability of a regulated entity's ePHI. A timely response to a security incident can be one of the best ways to prevent, mitigate, and recover from future cyberattacks. For example, responding to a single intrusion or inappropriate access can prevent a pattern of repeated malicious actions. It is extremely important that a regulated entity analyzes an incident to establish what has occurred and its root cause. Doing so will enable the regulated entity to use that information to update its security incident response plans. The Department has previously issued guidance addressing such activities as forming a security incident response team, identifying and responding to security incidents, mitigating harmful effects of and documenting a security incident, and breach reporting.^[594]

NIST also offers guidance for addressing security incidents.^[595] It describes four key activities with detailed descriptions and sample questions:

• Determine the goals of an incident response.
• Develop and deploy an incident response team or other reasonable and appropriate response mechanism.
• Develop and implement policy and procedures to respond to and report security incidents.
• Incorporate post-incident analysis into updates and revisions.

NIST has also issued comprehensive guidelines for incident handling, particularly for analyzing incident related data and determining the appropriate response to each incident.^[596] For example, the NIST Cybersecurity Framework addresses these activities as part of the core function of “[respond—a]ctions regarding a detected cybersecurity incident are taken.” ^[597] “Respond” supports the ability of the regulated entity “to contain the effects of cybersecurity incidents. Outcomes within this Function [include] incident management, analysis, mitigation, reporting, and communication.” ^[598]

Despite this existing guidance, OCR's enforcement experience indicates that many regulated entities have not met the existing standard, so we believe that additional specificity regarding their obligations and liability for incident response is warranted. Accordingly, the Department proposes to redesignate the standard for security incident procedures as 45 CFR 164.308(a)(12)(i), to add a paragraph heading to clarify the organization of the regulatory text, and to modify the regulatory text to clarify that a regulated entity would be required to implement written policies and procedures to “respond to,” rather than “address,” security incidents. Additionally, we propose to clarify expectations by adding an implementation specification for planning and testing at proposed 45 CFR 164.308(a)(12)(ii)(A)( 1 ) that would require a regulated entity to establish written security incident response plan(s) and procedures documenting how workforce members are to report suspected or known security incidents and how the regulated entity will respond to suspected or known security incidents.^[599]

Internal reporting is an essential component of security incident procedures.^[600] Plans and procedures for ( print page 954) reporting of suspected or known security incidents may address to whom, when, and how such incidents are to be reported. The recipient(s) and the content of such reports, according to such plans and procedures, may vary based on the type of incident and the role of the workforce member making the report. We do not propose to dictate the form, format, or content of such report. Rather, we believe that regulated entities would be best situated to identify the point(s) of contact for their organization ( e.g., Chief Information Security Officer, IT security team, business associate engaged to support incident response activities for the regulated entity) for such reports and the type of information they need to determine how to respond to the suspected or known security incident.

The proposal to require a regulated entity to establish written security incident response plans and procedures for how it will respond to suspected or known security incidents would align with the enhanced CPG for Third Party Incident Reporting because it would address the procedures for how and when a business associate would report to a covered entity or another business associate known or suspected security incidents, as required by proposed 45 CFR 164.314(a)(2)(i)(C).^[601]

Under proposed 45 CFR 164.308(a)(12)(ii)(A)( 2) and ( 3), the regulated entity would be required to implement written procedures for testing and revising the security incident response plan(s) and then, using those written procedures, review and test its security incident response plans at least once every 12 months and document the results of such tests. The regulated entity would also be required to modify the plan(s) and procedures as reasonable and appropriate, based on the results of such tests and the regulated entity's circumstances.

This proposal, if finalized, would include requirements that align with the Department's essential CPG for Basic Incident Planning and Preparedness to have effective responses to and recovery from security incidents.^[602] It also aligns with the Department's enhanced CPG for Centralized Incident Planning and Preparedness by requiring a regulated entity to maintain, revise, and test security incident response plans.^[603]

Additionally, the Department proposes to redesignate the implementation specification for response and reporting at 45 CFR 164.308(a)(6)(ii) as 45 CFR 164.308(a)(12)(ii)(B) and to rename it “Response.” We also propose to modify the existing implementation specification by separating it into two paragraphs: one at paragraph (a)(12)(ii)(B)( 1) for identifying and responding to suspected or known security incidents, and the other at paragraph (a)(12)(ii)(B)( 2) for mitigating, to the extent practicable, the harmful effects of suspected or known security incidents. The Department also proposes to add three additional paragraphs to this implementation specification. Proposed 45 CFR 164.308(a)(12)(ii)(B)( 3) would require a regulated entity to identify and remediate, to the extent practicable, the root cause(s) of suspected or known security incidents, while proposed 45 CFR 164.308(a)(12)(ii)(B)( 4 ) would require the regulated entity to eradicate the security incidents that are suspected or known to the regulated entity. We would expect eradication to include the removal of malicious software, inappropriate materials, and any other components of the incident from the regulated entity's relevant electronic information systems.^[604] Finally, proposed 45 CFR 164.308(a)(12)(ii)(B)( 5) would require a regulated entity to develop and maintain documentation of investigations, analyses, mitigation, and remediation for security incidents that are suspected or known. For example, verbal reports of a suspected or known security incident would be required to be documented in writing. Under proposed 45 CFR 164.316(b)(1), if finalized, a regulated entity would be required to maintain such documentation for six years from the date of its creation or the date when it last was in effect, whichever is later. These proposals are consistent with existing guidance described above and with other proposals or existing regulatory standards to secure health information.^[605]

o. Section 164.308(a)(13)(i)—Standard: Contingency Plan

The purpose of any contingency plan is to allow an organization to return to its daily operations as quickly as possible after an unforeseen event.^[606] The contingency plan protects resources, minimizes customer inconvenience, and identifies key staff, assigning specific responsibilities in the context of the recovery. Contingency plans are critical to protecting the availability, integrity, and security of data during unexpected adverse events. Contingency plans should consider not only how to respond to disasters such as fires and floods, but also how to respond to cyberattacks. Cyberattacks using malicious software, such as ransomware, may render an organization's data unreadable or unusable. In the event data is compromised by a cyberattack, restoring the data from backups may be the only option for recovering the data and restoring normal business operations. For example, the faulty software update by CrowdStrike made it impossible for health care systems worldwide to use their Windows-based systems.^[607] There were many instances where surgical procedures and health care appointments were cancelled, schedules upended, and pharmacies were unable to fill prescriptions. Regulated entities need to make and implement contingency plans they would use when such events occur to enable themselves to get back to their core functions of providing or paying for health care.

The Department and NIST have issued extensive guidance on contingency planning, including detailed descriptions of key activities, sample questions for regulated entities to consider when standing up a contingency plan, and information on how the results of the risk analysis feed into contingency plans.^[608] Unfortunately, many regulated entities have not implemented the required ( print page 955) planning and then have been unable to fully recover from ransomware attacks that bring down electronic systems that create, receive, maintain, or transmit ePHI. For example, a large health system that experienced a ransomware attack had to shut down services at multiple locations and encountered difficulties restoring those services. OCR's investigation indicated a potential failure to, among other things, implement contingency plans.^[609] Such planning is crucial for maintaining the resilience of a regulated entity's health IT.

To address these inadequacies in compliance and to protect the confidentiality, integrity, and availability of ePHI, the Department proposes to redesignate the standard for a contingency plan at 45 CFR 164.308(a)(7)(i) as proposed 45 CFR 164.308(a)(13)(i), to add a paragraph heading to clarify the organization of the regulatory text, and to modify the regulatory text to clarify it. The modified standard, as proposed, would require a regulated entity to establish (and implement as needed) a written contingency plan, consisting of written policies and procedures for responding to an emergency or other occurrence, including, but not limited to, fire, vandalism, system failure, natural disaster, or security incident, that adversely affects relevant electronic information systems.

The Department proposes a new implementation specification for criticality analysis at proposed 45 CFR 164.308(a)(13)(ii)(A). This would require a regulated entity to perform and document an assessment of the relative criticality of its relevant electronic information systems and technology assets in its relevant electronic information systems. The proposal would not limit this analysis to electronic information systems that create, receive, maintain, or transmit ePHI because other electronic information systems and/or technology assets may be crucial to ensuring the confidentiality, integrity, or availability of ePHI, providing patient care, and supporting other business needs. A prioritized list of specific relevant electronic information systems and technology assets in those electronic information systems would help a regulated entity to determine their criticality and the order of restoration.^[610]

Under this proposal, the implementation specification for establishing and implementing a data backup plan would be redesignated as proposed 45 CFR 164.308(a)(13)(ii)(B) and renamed “Data backups.” It would also be modified to clarify that the procedures to create and maintain exact retrievable copies of ePHI must be in writing, and to also require such procedures to include verifying that the ePHI has been copied accurately. For example, the ability to access ePHI from a remote location in the event of a total failure should be reflected in the procedures specified for data backups.

The proposed implementation specification for backing up information systems at proposed paragraph (a)(13)(ii)(C) would require a regulated entity to establish and implement written procedures to create and maintain backups of its relevant electronic information systems, including verifying the success of such backups. Establishing such procedures would ensure that the ePHI in relevant electronic information systems is both protected and available.

Additionally, the Department proposes to redesignate the implementation specification for disaster recovering planning as paragraph (a)(13)(ii)(D). We propose to clarify that a regulated entity would be required to establish (and implement as needed) written procedures to restore both its critical relevant electronic information systems and data within 72 hours of the loss, and to restore the loss of other relevant electronic information systems and data in accordance with its criticality analysis.^[611]

The Department proposes to clarify the implementation specification for emergency mode operation planning, redesignated as proposed 45 CFR 164.308(a)(13)(ii)(E), by clarifying that procedures must be written. We also propose to redesignate the implementation specification for testing and revision procedures as paragraph (a)(13)(ii)(F) and to clarify that procedures for testing and revising of the required contingency plans must be established in writing. We propose to require a regulated entity to review and implement its procedures for testing contingency plans at least once every 12 months, to document the results of such tests, and to modify those plans as reasonable and appropriate based on the results of those tests.

p. Section 164.308(a)(14)—Standard: Compliance Audit

The final standard we propose under 45 CFR 164.308(a) is a new standard for compliance audits at proposed 45 CFR 164.308(a)(14). For this proposed standard, the Department proposes to require regulated entities to perform and document an audit of their compliance with each standard and implementation specification of the Security Rule at least once every 12 months.

While the Security Rule does not currently require regulated entities to conduct internal or third-party compliance audits, such activities are important components of a robust cybersecurity program. The Government Accountability Office has published guidance on conducting cybersecurity performance audits for Federal agencies.^[612] Audits are typically conducted independently from information security management, and the function generally reports to the governing body of the regulated entity. This independence can provide an objective view of the regulated entity's policies and practices. According to the Institute of Internal Auditors, an internal audit provides “[i]ndependent and objective assurance and advice on all matters related to the achievement of objectives.” ^[613] An internal audit may be conducted by a business associate of a covered entity or a subcontractor of a business associate. These activities provide regulated entities with confidence in the effectiveness of their risk management plan. Thus, we believe that this proposal would aid a regulated entity in ensuring compliance with the Security Rule, and ultimately, protecting ePHI. We do not propose to specify whether the compliance audit should be performed by the regulated entity or an external party.^[614]

( print page 956)

q. Section 164.308(b)(1) and (2)—Standard: Business Associate Contracts and Other Arrangements

Vendor management and identification of risks in a supply chain are essential to controlling the introduction of new threats and risks to a regulated entity.^[615] NIST guidance explains that regulated entities, are permitted to include more stringent cybersecurity measures in business associate agreements than those required by the Security Rule.^[616] Such requirements would need to be agreed upon by both parties to the business associate agreement.^[617] The guidance also recommends establishing a process for measuring contract performance and terminating the contract if security requirements are not being met. Important considerations include: Is there a process for reporting security incidents related to the agreement? Are additional assurances of protections for ePHI from the business associate necessary? If so, where would such additional assurances be documented ( e.g., in the business associate agreement, service-level agreement, or other documentation) and how would they be met ( e.g., providing documentation of implemented safeguards, audits, certifications)?

The Security Rule requires a regulated entity to protect the confidentiality, integrity, and availability of all ePHI that it creates, receives, maintains, or transmits.^[618] It also requires a regulated entity to obtain written satisfactory assurances that its business associate will appropriately safeguard ePHI before allowing the business associate to create, receive, maintain, or transmit ePHI on its behalf.^[619] However, the Security Rule does not require a regulated entity to verify that entities that create, receive, maintain, or transmit ePHI on its behalf are in fact taking the necessary steps to protect such ePHI. The lack of such a requirement may leave a gap in protections from risks to ePHI related to regulated entities' vendors and supply chains. Accordingly, the Department proposes several modifications to the Security Rule to provide greater assurance that business associates and their subcontractors are protecting ePHI because a subcontractor to a business associate is also a business associate. The Department proposes to redesignate 45 CFR 164.308(b)(1) and (2) as proposed 45 CFR 164.308(b)(1)(i) and (ii), respectively. Additionally, we propose to make a technical correction to the standard for business associate contracts and other arrangements for organizational clarity, separating proposed paragraph (b)(1)(i) into paragraphs (b)(1)(i)(A) and (B). We believe this is a non-substantive change that would have no effects on any regulatory, recordkeeping, or reporting requirement, nor would it change the Department's interpretation of any regulation. We also propose to modify both to require a regulated entity to verify that the business associate has deployed the technical safeguards required by 45 CFR 164.312 ^[620] in addition to obtaining satisfactory assurances that its business associate would comply with the Security Rule.^[621] To assist regulated entities in complying with the new standard, we propose to redesignate the implementation specifications at 45 CFR 164.308(b)(3) as 45 CFR 164.308(b)(2) and propose to add an implementation specification for written verification at proposed 45 CFR 164.308(b)(2)(ii) that would require the regulated entity to obtain written verification from the business associate that the business associate has deployed the required technical safeguards.^[622] The Department proposes to require that the regulated entity obtain this written verification documenting the business associate's deployment of the required technical safeguards at least once every 12 months.^[623] Additionally, we propose that the verification include a written analysis of the business associate's relevant electronic information systems.^[624] The written analysis would be required to be performed by a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of ePHI to verify the business associate's compliance with each standard and implementation specification in 45 CFR 164.312.^[625] We also propose to require that the written verification be accompanied by a written certification by a person who has the authority to act on behalf of the business associate that the analysis has been performed and is accurate.^[626] The proposal would permit the parties to determine the appropriate person to perform the analysis and how that person is engaged or compensated. This person may be a member of the covered entity's or business associate's workforce or an external party.

This proposed new requirement that a regulated entity obtain written verification from its business associates that they have deployed technical safeguards combined with the existing requirement to obtain written satisfactory assurances that they safeguard ePHI, aligns with the Department's essential CPG for Vendor/Supplier Cybersecurity Requirements.^[627] This CPG calls for regulated entities to identify, assess, and mitigate risks to ePHI used by or disclosed to business associates.^[628]

r. Section 164.308(b)(3)—Standard: Delegation To Business Associate

Based on the OCR's investigations and enforcement experience, we believe that some regulated entities are not aware that they retain compliance responsibility for implementing requirements of the Security Rule, even when they have delegated the functions of designated security official to a business associate. Therefore, the Department proposes a new standard for delegation to a business associate at proposed 45 CFR 164.308(b)(3). The proposed standard would clarify that a regulated entity may permit a business associate to serve as its designated security official.^[629] However, a regulated entity that delegates actions, activities, or assessments required by the Security Rule to a business associate remains liable for compliance with all the applicable provisions of the Security Rule.^[630]

4. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular. For any proposed timeframe that a commenter believes is not appropriate, we request comment and explanation on a more appropriate timeframe. ( print page 957)

a. Whether the Department should require a regulated entity to implement any additional administrative safeguards. If so, please explain.

b. Whether the Department should not require a regulated entity to implement any of the existing or proposed standards for implementation specifications. If so, please explain.

c. Whether there are additional implementation specifications that should be adopted for any of the standards for administrative safeguards.

d. Whether the Department should provide any exceptions to the administrative safeguards or related implementation specifications. If so, please explain when and why any exceptions should apply.

e. Whether once every 12 months is the appropriate frequency between reviews of policies, procedures, and other activities required by the other standards for administrative safeguards.

f. Whether there are any special considerations for business associates and business associate agreements that the Department should be aware of with respect to administrative safeguards.

g. Whether there are any requirements for business associates and business associate agreements that the Department should include in administrative safeguards that it did not propose.

h. Whether the Department should require covered entities to report to their business associates (or business associates to their subcontractors) the activation of the covered entities' (or business associates') contingency plans. If so, please explain the appropriate circumstances of and the appropriate amount of time for such notification.

i. Whether once every 12 months is an appropriate length of time in which a covered entity must verify and document that a business associate has deployed technical safeguards pursuant to the requirements.

j. Whether the Department should require covered entities to obtain satisfactory assurances and verify that a business associate has implemented physical or other safeguards in addition to deploying technical safeguards before permitting it to create, receive, maintain, or transmit ePHI on its behalf.

k. Whether on an ongoing basis, but at least once every 12 months and when there is a change to a regulated entity's environment or operations that affects ePHI, is the appropriate frequency for updating the technology asset inventory and network map?

l. Whether on an ongoing basis, but at least once every 12 months and when there is a change to the regulated entity's environment or operations that affects ePHI, is the appropriate frequency for performing a risk analysis?

m. Whether there are additional events for which the Department should require a regulated entity to update its risk analysis. If so, please explain.

n. Whether the Department should include or exclude any specific circumstances from its explanation of environmental or operational changes when determining whether review or update of the written inventory of technology assets and network map or review of the risk analysis written assessment is warranted.

o. Whether the proposed requirement in the standard for evaluation, to perform a written technical and nontechnical evaluation within a reasonable period of time before making a change in the regulated entity's environment or operations pursuant to the requirements, is sufficiently clear. If not, how should the Department clarify it? For example, should the Department require a specific amount of time, and if so, what length of time?

p. Whether at least once every 12 months is the appropriate frequency for reviewing and updating written policies and procedures for patch management, sanctions policies and procedures information system activity review, workforce security, and information access management.

q. Whether as reasonable and appropriate in response to changes in the risk analysis, but at least once every 12 months, is the appropriate frequency for reviews of a regulated entity's written risk management plan.

r. Whether the proposed frequency for security awareness training is appropriate.

s. Whether the proposed substance of the security awareness training is appropriate, and any recommendations for additional required content.

t. Whether the proposed timelines for applying patches, updates, and upgrades are appropriate.

u. Whether the Department should set a time limit for applying patches, updates, and upgrades to configurations of relevant electronic information systems to address moderate and low risks. If so, please explain and provide a recommendation.

v. Whether the amount of time regulated entities currently retain records of information system activity varies by the type of record, and for how long such records are retained.

w. Whether the Department should specify the length of time for which records of information system activity should be retained. If so, please explain.

x. Whether the Department should require that a regulated entity notify other regulated entities of the termination of a workforce member's access to ePHI in less than 24 hours after the workforce member's termination. If so, please explain what would be an appropriate period of time ( e.g., three business hours, 12 hours).

y. Whether at least once every 12 months is the appropriate frequency for testing security incident response plans, documenting the results, and revising such plans.

z. Whether it is reasonable and appropriate to require that regulated entities restore loss of critical relevant electronic information systems and data in 72 hours or less.

aa. Whether the Department should require a regulated entity to restore all of its relevant electronic information systems and data within 72 hours?

bb. Whether the Department should require some regulated entities to restore their relevant electronic information systems and data in less than 72 hours? If so, please explain.

cc. Whether at least once every 12 months is the appropriate frequency for the testing of contingency plans?

dd. Whether annual auditing of a regulated entity's compliance with the Security Rule is appropriate.

ee. Whether the Department should specify the level of detail or standard required for the annual compliance audit. If so, please explain.

ff. Whether the Department should require a regulated entity to obtain written verification of their business associates' implementation of the administrative and physical safeguards that are required by the Security Rule, in addition to the proposed requirement to obtain verification of implementation of the technical safeguards. If so, please explain.

gg. Whether there are other requirements for which the Department should require that the person performing them have a specific level or type of expertise. If so, please explain.

E. Section 164.310—Physical Safeguards

1. Current Provisions

A person with physical access to electronic media or a regulated entity's electronic information systems that create, receive, maintain, or transmit or that otherwise affect the confidentiality, integrity, and availability of ePHI might have the opportunity to change the configurations of its relevant electronic information systems, install malicious software or otherwise adversely affect technology assets in its relevant ( print page 958) electronic information systems, change information, or access ePHI or other sensitive information.^[631] Any of these actions has the potential to adversely affect the confidentiality, integrity, or availability of ePHI, which means that physical safeguards for electronic media and a regulated entity's relevant electronic information systems are critical to protecting the security of ePHI. Thus, the physical safeguards standards address the essential requirements for regulated entities to apply to limit physical access to their relevant electronic information systems to only authorized workforce members. As discussed above, ePHI is increasingly transmitted using interconnected systems that rely on cloud computing. The shift to a cloud-based infrastructure may increase regulated entities' reliance on business associates to maintain and access ePHI stored in the cloud.^[632] Additionally, the shift to cloud computing enables regulated entities' workforce members to access ePHI and relevant electronic information systems from a greater number of locations. Accordingly, regulated entities must appropriately expand and/or ensure that applied physical safeguards take into account these new arrangements.

Section 164.310 includes the four standards with which a regulated entity must comply to physically secure relevant electronic information systems and the premises where they are located. These standards require regulated entities to implement physical safeguards for facility access controls, workstation use, workstation security, and device and media controls in a manner that conforms with 45 CFR 164.306(c), the general compliance provision for the security standards.

As discussed above in greater detail, physical safeguards encompass the physical measures, and related policies and procedures, to protect relevant electronic information systems and related buildings and equipment from natural and environmental hazards, and unauthorized intrusion.^[633] The standard for facility access controls applies to protect the physical premises, while the standards for workstation use, workstation security, and device and media controls are aimed at protecting the electronic information systems and electronic media that create, receive, maintain, or transmit ePHI or that otherwise affect its confidentiality, integrity, and availability.

The standard for facility access controls at 45 CFR 164.310(a)(1) requires a regulated entity to implement policies and procedures that limit physical access to electronic information systems and facilities that contain those systems. Section 164.310(a)(1) also requires a regulated entity to ensure its policies and procedures allow persons who are properly authorized to access its facilities.

Under 45 CFR 164.310(a)(2), a regulated entity must implement the standard for facility access controls in accordance with four implementation specifications. The implementation specification for contingency operations addresses the establishment (and implementation as needed) of procedures that allow for facility access in support of the restoration of lost data under a disaster recovery plan and emergency mode operations.^[634] Section 164.310(a)(2)(ii) contains the specification for a facility security plan and addresses the implementation of policies and procedures to safeguard facilities and equipment in such facilities from unauthorized physical access, tampering, and theft. The implementation of procedures for role-based access control, including for visitors and for access to software programs for testing and revision is addressed in 45 CFR 164.310(a)(2)(iii), while 45 CFR 164.310(a)(2)(iv) addresses the implementation of policies and procedures for the documentation of repairs and modifications to physical security components of a facility, such as hardware, walls, doors, and locks.

Section 164.310(b) requires a regulated entity to implement policies and procedures specifying proper workstation functions, the manner in which those functions are to be performed, and the physical attributes of the environment for where specific workstations or classes of workstation used for accessing ePHI.^[635] This standard is not accompanied by standalone implementation specifications, compared to the standards for facility access controls at 45 CFR 164.310(a) and device and media controls at 45 CFR 164.310(d). Section 164.310(c), the standard for workstation security, also is not accompanied by standalone addressable or required implementation specifications, but it does require a regulated entity to implement physical safeguards that restrict all workstations, such as a laptop or desktop computer or any other device that performs similar functions, that access ePHI to authorized users.^[636]

Device and media controls can help regulated entities respond to and recover from security incidents and breaches.^[637] Proper understanding of and implementation of such controls may enable regulated entities to quickly determine which devices and electronic media may be implicated in an actual or suspected security incident, or breach, and respond accordingly.^[638] For example, if cybercriminals gained access to an organization's network by exploiting a vulnerability present in a particular electronic device, a robust and accurate inventory and tracking process could identify how many devices are affected and where they are located. With this information, a regulated entity should be able to make more effective use of its resources and respond more effectively to an actual or suspected security incident or breach involving such devices. Thus, it is important for regulated entities to implement the device and media controls required under 45 CFR 164.310(d). Accordingly, the standard for device and media controls at 45 CFR 164.310(d), requires a regulated entity to implement policies and procedures to govern how hardware and electronic media containing ePHI are received or removed from a facility and within a facility. Section 164.310(d)(2) includes two required and two addressable implementation specifications. Paragraphs (d)(2)(i) and (ii) on disposal and media re-use, respectively require a regulated entity to implement policies and procedures that address the final disposition of ePHI and the hardware or electronic media on which it is stored, and the removal of ePHI before the electronic media is re-used. Section 164.308(d)(2)(iii) addresses the ( print page 959) maintenance of a record of the movement of hardware and electronic media and any person responsible for such hardware or electronic media, while the provision on data backup and storage at 45 CFR 164.310(d)(2)(iv) addresses the creation of a retrievable, exact copy of ePHI before moving the equipment.

2. Issues To Address

The Department has concerns regarding the effectiveness of the language used in the physical safeguards in 45 CFR 164.310 for the same reasons discussed in the context of 45 CFR 164.306 and 164.316. For example, while 45 CFR 164.310 contemplates that a regulated entity must implement the standards and implementation specifications required under 45 CFR 164.310 in accordance with the general documentation and maintenance requirements found in 45 CFR 164.306 and 164.316, at least one court has stated that compliance obligations are limited to the plain words of regulatory text and that a requirement to “implement” does not mean that a requirement must be in place throughout the regulated entity's enterprise.^[639] Additionally, the standards for facility access controls, workstation use, and device and media controls all require a regulated entity to implement policies and procedures, while the standard for workstation security requires regulated entities to implement physical safeguards. The differences in regulatory text among these provisions could be interpreted to mean that a regulated entity's obligations differ depending on whether a provision requires it to implement only policies and procedures or whether the provision requires the implementation of something more. This may confuse regulated entities and lead some to believe that less comprehensive protection is needed for ePHI subject only to policies and procedures.

The Department believes that the current Security Rule provides a clear path for regulated entities to protect the confidentiality, integrity, and availability of ePHI. However, as discussed above, we also believe recent caselaw has created confusion about the steps regulated entities must take to adequately protect the confidentiality, integrity, and availability of ePHI, as required by the statute. Further, the conditions highlighted by caselaw may also cause regulated entities to misinterpret the regulatory text that connects the current maintenance requirement at 45 CFR 164.306(e), the documentation requirement at 45 CFR 164.316, and the requirement to implement physical safeguards. For example, regulated entities may be confused about how 45 CFR 164.316 requires a regulated entity to document the policies and procedures for specific physical safeguard in 45 CFR 164.310 (or across any other safeguard). In this case, the regulated entity also might not apply the implementation specifications to retain, make available, and review documentation of how it has operationalized the physical safeguard. Failing to connect these provisions would lead to inadequate protection of ePHI and/or an inability to demonstrate compliance with the Security Rule.

Our experience enforcing the Security Rule provides examples of the types of breaches that can occur because of absent or insufficient physical safeguards:

• An investigation of a large health system indicated potential failures to implement policies and procedures and facility access controls to limit physical access to the electronic information systems housed within a large data support center. While the health system did have video surveillance, the investigation found indications that laptops were stored in an interior room that was unlocked and the facility did not have an alarm system.^[640]

• A large university hospital experienced a breach of unsecured PHI when it lost an unencrypted flash drive and unencrypted laptop. The Department's investigation found that the covered entity may have failed to use device and media controls, which might have prevented the loss of these devices.^[641]

Given the increased portability of devices, media, workstations, and information systems, such components may often be located outside of a regulated entity's physical location. For example, OCR has investigated several incidents involving portable electronic media and mobile workstations that were removed from the regulated entity's physical environment and subsequently lost. As a result, the Department believes that we should more broadly construe the physical environment where ePHI is stored and accessed because it is essential that regulated entities have policies and procedures in place to address the portability of components of their information systems, as well as the ability of workforce members to access such information systems offsite using portable workstations.

Additionally, the standard for device and media controls at 45 CFR 164.310(d)(1) applies only to devices and media, rather than all technology assets that may be components of a regulated entity's relevant electronic information systems. The Department is concerned that a regulated entity may have other types of technology assets that may either create, receive, maintain, or transmit ePHI or otherwise affect its confidentiality, integrity, or availability and that can be removed from, brought to, or moved within its facilities. The confidentiality, integrity, or availability of the regulated entity's ePHI could be negatively affected in the absence of written policies and procedures governing the movement of such technology assets.

Finally, we believe that it is important to address several issues in the standards and implementation specifications for the physical safeguards that are also addressed in other proposals: addressing the Department's expectations regarding implementation specifications; ^[642] memorializing policies and procedures in writing; documenting the implementation of the aforementioned policies and procedures; reviewing such policies and procedures on a regular cadence; modifying such policies and procedures when reasonable and appropriate; ^[643] and clarifying the scope of the electronic information systems and their components that regulated entities are expected to consider when establishing their policies and procedures.^[644]

3. Proposals

The Department proposes to retain the four standards that comprise the Security Rule's physical safeguards required by 45 CFR 164.306 and codified in 45 CFR 164.310. However, we propose several modifications to 45 CFR 164.310 to address the issues identified above.

a. Section 164.310—Physical Safeguards

The Department proposes to expand the introductory language at 45 CFR ( print page 960) 164.310 to clarify that the Security Rule requires that physical safeguards be applied to all ePHI in the possession of the regulated entity, that is, throughout the regulated entity's facilities. The Department also proposes to expand this section to expressly require a regulated entity to implement physical safeguards in accordance with not only 45 CFR 164.306, but also 45 CFR 164.316 to connect the overarching documentation requirements.

Consistent with the proposals to revise the general requirements in 45 CFR 164.306(c) and (d), the Department proposes to remove any distinction between addressable and required implementation specifications in this section such that all specifications would be required. Also consistent with changes proposed elsewhere in this NPRM, the Department proposes to modify all four physical safeguard standards to require that the requisite policies and procedures be in writing ^[645] and implemented throughout the enterprise.^[646] Under this proposal, a regulated entity that could not produce a written policy describing how it will implement a required physical safeguard and demonstrate that the safeguard is in effect and operational throughout the enterprise would not be in compliance with the standard. Consistent with our proposals to require that regulated entities maintain their administrative safeguards, the Department also proposes to require a regulated entity to maintain its security measures by reviewing and testing the required security measures at least once every 12 months, and by modifying the same as reasonable and appropriate. Additionally, we propose to modify certain standards and implementation specifications to ensure that regulated entities understand their obligations to ensure the confidentiality, integrity, and availability of ePHI by implementing physical safeguards to protect their relevant electronic information systems and/or the technology assets in their relevant electronic information systems.

b. Section 164.310(a)(1)—Standard: Facility Access Controls

The Department proposes to modify the standard for facility access controls at 45 CFR 164.310(a)(1) to clarify that the policies and procedures required by this standard must be in writing and address physical access to all of a regulated entity's relevant electronic information systems and the facility or facilities in which these systems are housed and to add a paragraph to clarify the organization of the regulatory text. The Department also proposes to modify the implementation specifications associated with the standard for facility access controls. Specifically, we propose to modify the implementation specifications for contingency operations, facility security plan, and access control and validation procedures at 45 CFR 164.310(a)(2)(i) through (iii) to clarify that we expect a regulated entity to not only establish and implement policies and procedures, but also that we expect them to be in writing.

The Department's proposal would also require that the procedures for contingency operations proposed at 45 CFR 164.310(a)(2)(i) support the regulated entity's contingency plan, instead of the current requirement specifying that the procedures support the restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.^[647] This proposal would align the implementation specification for contingency operations with the standard for contingency planning at proposed 45 CFR 164.308(a)(13)(i) by specifically ensuring that the written policies and procedures support the required contingency plan. It also would avoid duplicating the implementation specification for disaster recovery planning at proposed 45 CFR 164.308(a)(13)(ii)(D), which would require a regulated entity to address the restoration of lost data and systems in the disaster recovery plan component of its contingency plan. We propose to modify 45 CFR 164.310(a)(2)(ii) to clarify that the written policies and procedures that constitute the facility security plan must apply to all of the regulated entity's facilities and equipment contained within those facilities. The Department proposes to retitle the implementation specification for access control and validation procedures at 45 CFR 164.310(a)(2)(iii) as “Access management and validation procedures” and to require regulated entities to establish and implement written procedures to both authorize and manage a person's role-based access to facilities.

In the implementation specification for maintenance records, the Department proposes at 45 CFR 164.310(a)(2)(iv), to change the provision heading to “Physical maintenance records” and to add security cameras to the list of examples of physical security components about which a regulated entity is required to implement written policies and procedures to document repairs and modifications. Both proposals are consistent with and recognize the evolution of the role that technology plays in managing and granting physical access to facilities.

Consistent with our proposals to add maintenance requirements where we believe it is necessary for regulated entities to review, test, and modify their security measures on a particular cadence, we also propose to add an implementation specification for maintenance at proposed 45 CFR 164.310(a)(2)(v). The maintenance provision would require that, for each facility, a regulated entity review and test its written policies and procedures at least once every 12 months, and to modify those policies and procedures as reasonable and appropriate based on that review.

c. Section 164.310(b)(1)—Standard: Workstation Use and Section 164.310(c)—Standard: Workstation Security

Further, in the standards for workstation use and workstation security at 45 CFR 164.310(b) (redesignated as proposed 45 CFR 164.310(b)(1) and (c), respectively), the Department proposes several changes that would recognize the increasingly mobile nature of ePHI and workstations that connect to the information systems of regulated entities. The purpose of these proposals is to ensure that regulated entities properly consider physical safeguards for all workstations, including those that are mobile, and not only those that are located in regulated entities' facilities. The Department also proposes to modify both standards to clarify the organization of the regulatory text. The Department proposes to modify the standard for workstation use to clarify that policies and procedures established by a regulated entity to govern the use of workstations be in writing and address all workstations that access ePHI or the regulated entity's relevant electronic information systems. These proposed changes are consistent with the Department's longstanding expectations and other proposals in this NPRM described above. In 45 CFR 164.310(b)(2)(i)(C), the Department proposes to require a regulated entity to establish and implement written policies and procedures that, among other things, specify the physical attributes of workstation surroundings, including the removal of workstations from a facility and the movement of workstations within and outside of a facility. This proposal is consistent with ( print page 961) the proposed revision to the definition of “workstation” discussed above. Additionally, we propose to add an implementation specification for maintenance at proposed 45 CFR 164.310(b)(2)(ii) to require that a regulated entity review and test its written policies and procedures at least once every 12 months, and to modify those policies and procedures as reasonable and appropriate based on that review.

Relatedly, the Department proposes to modify the standard for workstation security at 45 CFR 164.310(c) to require a regulated entity to implement physical safeguards for workstations that access ePHI or relevant electronic information systems to comply with its written policies and procedures for workstation use. This proposal would also make clear that such physical safeguards must be modified in response to any modifications to the written policies and procedures for workstation use. As part of their policies and procedures for workstation security, the Department encourages regulated entities to consider, among other things, whether there are workstations located in public areas or other areas that are more vulnerable to theft, unauthorized use, or unauthorized viewing; whether such devices should be relocated; the physical security controls for workstations that are in use ( e.g., cable locks, privacy screens, secured rooms, cameras) and whether they are easy to use; and whether there are additional physical security controls that could reasonably be put into place.^[648] Additionally, consistent with the Department's proposal to require that a regulated entity provide role-based security awareness training on its Security Rule policies and procedures,^[649] the Department expects that such training would address the physical safeguards it has implemented, particularly those policies and procedures for mobile devices that are used to create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI.

d. Section 164.310(d)(1)—Standard: Technology Asset Controls

The Department proposes to modify the standard at 45 CFR 164.310(d)(1) by changing the heading to “Technology asset controls” from “Device and media controls,” and replacing “hardware and electronic media” in 45 CFR 164.310(d)(1) and (2) with “technology assets.” We believe that this modification would more accurately capture the various categories of components of a regulated entity's relevant electronic information systems that may be received in, removed from, or moved within a facility and that also affect the confidentiality, integrity, or availability of ePHI. Thus, we believe that this modification would provide regulated entities with a clearer understanding of their compliance obligations with respect to the physical safeguards that should be implemented to protect ePHI when technology assets are received by, removed from, or moved within a facility. While we are not proposing other significant changes to 45 CFR 164.310(d)(1) at this time, we remind regulated entities to consider the appropriateness of the policies and procedures they have implemented with respect to the movement of technology assets that maintain ePHI into and out of their facilities and the movement of these items within their facilities. The processes a regulated entity chooses to implement to govern the movement of technology assets may vary based on the type of technology asset.^[650] For example, once installed, a server or desktop computer may not need to be moved for the entirety of its lifecycle within the regulated entity, while portable electronic devices and media, such as smartphones, tablets, and USB flash drives are designed to be mobile and may move frequently into, out of, and within a regulated entity's facilities.^[651] Thus, the regulated entity's policies and procedures must account for these differences.^[652] Further, we note that the proposed definition of workstation includes mobile devices. Mobile devices that serve as workstations are subject to the requirements in this paragraph and those in paragraphs (b) and (c).

The Department also proposes to modify the standard at 45 CFR 164.310(d)(1) to clarify the organization of regulatory text and to clarify its longstanding expectations that policies and procedures must be in writing and to replace “contain” with “maintain,” consistent with terminology used throughout the HIPAA Rules. The Department believes that having written policies for the disposal of ePHI and the technology assets on which it is stored and for the removal of ePHI from electronic media such that the ePHI cannot be recovered continues to be important to ensuring the physical safety of ePHI. Improper disposal of technology assets puts the ePHI stored in or on such assets at risk for a potential breach, and as discussed elsewhere, data breaches can result in substantial costs to regulated entities and the individuals affected by the breach. We also propose in the related implementation specifications at 45 CFR 164.310(d)(2)(i) and (ii) to require that written policies and procedures for disposal of ePHI and sanitization of electronic media be tied to current standards for sanitizing electronic media before the media are made available for re-use.^[653] For example, photocopiers today are often connected to the same network as workstations and generally store the information, including ePHI, transmitted to them. This capability is a significant change from photocopier capabilities that existed when the Security Rule was first issued in 2003. Under this proposal, a regulated entity would be required to include in its written policies and procedures for disposing of ePHI, and the technology assets on which it is maintained, policies and procedures addressing ePHI maintained on photocopiers, consistent with the current standards for disposing and removing ePHI from electronic media.^[654]

We have previously explained in guidance that a regulated entity should consider all of the following as part of its risk analysis:

• Disposal of hardware and software, and the documentation of such disposal.
• Destruction of ePHI in such a manner that it cannot be recreated.
• Secure removal of ePHI that was previously stored on hardware or electronic media such that it cannot be accessed and reused.
• The identification of all removable media and their use (e.g., CDs/DVDs, USB flash drives). ( print page 962)
• The removal of all ePHI from reusable media before the media are reused.^[655]

Our guidance describes these considerations in greater detail. For example, regulated entities should consider how to address the replacement of technology assets, including devices and media.^[656] Technology assets that need to be replaced should be decommissioned, meaning that they are taken out of service before the final disposition of such assets.^[657] Steps a regulated entity should consider as part of its decommissioning process include: ensuring technology assets are securely erased and then either securely destroyed or recycled; ensuring that the regulated entity's technology asset inventory is updated to accurately reflect the status of decommissioned technology assets or technology assets slated to be decommissioned; and ensuring that privacy is protected through proper migration to another electronic information system or total destruction of the ePHI.^[658]

The Department proposes to remove the implementation specifications for accountability and data backup and storage at 45 CFR 164.310(d)(2)(iii) and (iv). We believe that the accountability provisions would be subsumed and replaced by the proposed standard for technology asset inventory at proposed 45 CFR 164.308(a)(1)(i). Thus, when the proposed new standard and implementation specifications are read together, the written policies and procedures that govern the receipt and removal of technology assets that maintain ePHI into and out of a facility, and the movement of these assets within the facility, should include tracking relevant information in the technology asset inventory. Similarly, we are proposing to delete the specification for data backup and storage because it is redundant to the administrative safeguard on data backups at proposed 45 CFR 164.308(a)(13)(ii)(B).

As referenced above, in place of the implementation specifications we are proposing to delete, the Department proposes a new implementation specification at proposed 45 CFR 164.310(d)(2)(iii) that would require a regulated entity to review and test the written policies and procedures related to the implementation specifications for technology assets at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate. Such environmental or operational changes may range from new and emerging threats to the confidentiality, integrity, or availability of ePHI ( e.g., a new virus) to the adoption of new technology assets by the regulated entity ( e.g., a new operating system, new types of workstations). Given the constant evolution of IT and methods for restoring data that has been disposed of or was on electronic media that has been sanitized, the Department believes that it is essential for a regulated entity to at least consider the reasonableness and appropriateness of its policies and procedures for disposal and electronic media sanitation, not only annually, but also in the face of any environmental or operational changes. We expect that pursuant to our proposals to strengthen the standard for risk analysis, a regulated entity would be able to identify such environmental and operational changes before they occur.

4. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether every 12 months is an appropriate frequency for review of a regulated entity's written policies and procedures for physical safeguards. If not, please explain.

b. Whether the written policies and procedures for physical safeguards should be reviewed at different intervals, based on the specific standard or implementation specification. If so, please explain.

c. Whether the Department should include additional examples in regulatory text at proposed 45 CFR 164.310(a)(2)(iv) of physical components of a facility related to security for which there should be written policies and procedures to document repairs and modifications.

d. Whether the standard at proposed 45 CFR 164.310(d)(1) and its associated implementation specifications at paragraph (d)(2) should apply to technology assets that do not maintain ePHI, but do access the regulated entity's relevant electronic information systems.

F. Section 164.312—Technical Safeguards

1. Current Provisions

Section 164.312 includes five standards for technical safeguards, which are the requirements concerning the implementation of technology and technical policies and procedures to protect the confidentiality, integrity, and availability of ePHI and related information systems. A regulated entity must comply with the standards for technical safeguards in accordance with 45 CFR 164.306(c), the provision that describes the general rules for the security standards.

Under 45 CFR 164.312(a)(1), a regulated entity is required to establish policies and procedures for electronic information systems to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR 164.308(a)(4). Regulated entities may comply with this standard by implementing a combination of access control methods and technical controls, consistent with the implementation specifications for this standard. The Security Rule does not identify a specific access control method or technology to implement. Regardless of the technology or information system used, access controls should be appropriate for the workforce member's role and/or function.^[659] For example, a workforce member responsible for monitoring and administering information systems with ePHI, such as an administrator or a superuser,^[660] should only have access to ePHI as appropriate for their role and/or job function.

The implementation specifications that provide instructions for satisfying the access control standard are found at 45 CFR 164.312(a)(2). Two are required and two are addressable.^[661] The implementation specifications address unique user identifiers,^[662] emergency access procedures,^[663] automatic logoff,^[664] and encryption and decryption.^[665] The implementation ( print page 963) specification for unique user identification requires a regulated entity to assign unique identifiers to users to facilitate the identification of specific users of an information system.^[666] By assigning a unique identifier to each user, a regulated entity can track the specific activity of that user when they are logged into an information system and hold the user accountable for functions they perform in the information system when they access that system.

Under the implementation specification for emergency access procedures, a regulated entity is required to establish procedures, such as documented operational practices and instructions to workforce members, for obtaining access to necessary ePHI during an emergency and to implement such procedures as needed.^[667] In accordance with this implementation specification, a regulated entity must identify the types of situations in which its normal procedures for accessing an information system or application that contains ePHI may not work and establish procedures for obtaining access in those situations.^[668] These procedures must be established prior to an emergency to instruct workforce members on possible ways to gain access to needed ePHI where, for example, the electrical system has been severely damaged or rendered inoperative, or where a software update fails and prevents the regulated entity from accessing ePHI in its EHR.

The implementation specification for automatic logoff associated with the standard for access control addresses the need for a regulated entity to, when reasonable and appropriate, implement electronic procedures that terminate an electronic session after a period of inactivity.^[669] Automatic logoff is an effective way to prevent unauthorized users from accessing ePHI on a workstation when it is left unattended for a period of time.^[670] While many applications have configuration settings that automatically log a user out of the system after a period of inactivity, some systems have more limited capabilities and may activate a screen saver that is password protected.^[671]

The implementation specification under the standard for access control addresses encryption and decryption and requires regulated entities, when it is reasonable and appropriate, to implement a mechanism to encrypt and decrypt ePHI.^[672] Encrypting data, including ePHI, reduces the likelihood that anyone other than the party that has the key to the encryption algorithm would be able to decrypt ( i.e., translate) the data and convert it into plain, comprehensible text.^[673]

The standard for audit controls requires a regulated entity to implement hardware, software, and/or procedural mechanisms that record and examine activity in electronic information systems that contain or use ePHI. Most electronic information systems provide some level of audit controls with a reporting method, such as audit reports.^[674] These controls are useful for recording and examining information system activity, especially when determining whether a security violation has occurred.^[675] The Security Rule does not identify data that must be gathered by the audit controls or how often the audit reports should be reviewed.^[676] Instead, a regulated entity must consider its risk analysis and organizational factors, such as current technical infrastructure and hardware and software security capabilities, to determine reasonable and appropriate audit controls for information systems that contain or use ePHI.^[677] The audit controls standard has no implementation specifications.

Section 164.312(c)(1), the standard for integrity, requires a regulated entity to implement policies and procedures to protect ePHI from improper alteration or destruction. The integrity of data can be compromised by both technical and non-technical sources. Workforce members or business associates may make accidental or intentional changes that improperly alter or destroy ePHI. Data can also be altered or destroyed without human intervention, such as by electronic media errors or failures.^[678] The purpose of this standard is to establish and implement policies and procedures for protecting ePHI from being compromised regardless of the source. Improperly altered or destroyed ePHI can result in clinical quality problems for a covered entity, including patient safety issues.^[679]

Section 164.312(c)(2) contains the addressable implementation specification for the integrity standard that requires a regulated entity, when reasonable and appropriate, to implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. To determine which electronic mechanisms should be implemented to ensure the integrity of ePHI, a regulated entity must consider the various risks to the integrity of ePHI identified during the risk analysis. Once a regulated entity has identified risks to the integrity of its data, it must identify security measures that will reduce the risks.^[680]

The standard for person or entity authentication at 45 CFR 164.312(d) requires a regulated entity to establish policies and procedures for verifying that a person seeking access to ePHI is the one claimed. This standard addresses technical controls for ensuring access is allowed only to those persons or software programs that have been granted access rights under the administrative safeguard for information access management at 45 CFR 164.308(a)(4). This standard has no implementation specifications.

Under the standard for transmission security at 45 CFR 164.312(e)(1), a regulated entity is required to implement technical security measures to guard against unauthorized access to ePHI when transmitted electronically, such as through the internet. A regulated entity must identify the available and appropriate means to protect ePHI as it is transmitted, select appropriate solutions, and document its decisions.^[681]

The two addressable implementation specifications for the transmission security standards are under 45 CFR 164.312(e)(2). The implementation specification for integrity controls requires a regulated entity, when it is reasonable and appropriate, to implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until the ePHI has been disposed.^[682] The implementation specification for encryption requires a regulated entity, when it is reasonable and appropriate, to implement a mechanism to encrypt ePHI.

( print page 964)

2. Issues To Address

While the intention of 45 CFR 164.312 is for regulated entities to develop and put into place technical controls, the Department is aware that regulated entities have not always achieved the degree of protection for ePHI that we intended. Absent a definition of “implement,” some regulated entities might interpret the term to mean something other than implementing technical controls to ensure the confidentiality, integrity, and availability of ePHI. This misinterpretation may leave ePHI partially unprotected because regulated entities may not implement safeguards throughout their enterprise. As discussed above with respect to both the administrative and physical safeguards, the Department is also concerned that regulated entities are not making the connection between the maintenance requirement at 45 CFR 164.306(d) and the requirement to implement technical safeguards, and therefore, are not reviewing or updating their policies and procedures for technical safeguards. Additionally, the Department believes that regulated entities may not be recognizing that their obligations under the Security Rule to protect ePHI are not limited to protecting electronic information systems that create, receive, maintain, or transmit ePHI, but necessarily include other electronic information systems that affect the confidentiality, integrity, or availability of ePHI.

While the Security Rule relies on a flexible and scalable approach to compliance, the health care industry's shift to a digital environment has substantially increased both the risk to ePHI and the prevalence of technological solutions for addressing those risks. Additionally, the cost of such solutions has, in many cases, decreased over time, as is often the case with technology. For example, when the original Security Rule was published, tools to encrypt ePHI had limited availability, were more costly, and were not user-friendly, particularly for small health care providers.^[683] By contrast, in 2024, the technical ability to encrypt data may be seamless in many applications, inexpensive, and widely available in commercial software and hardware products.^[684] Where an encryption solution is not integrated into an application, software, or hardware, third-party solutions are often available.^[685] Thus, we do not believe that it is appropriate for such provisions to be “addressable.” ^[686]

Based on its own investigations and compliance reviews, news reports, and published studies, the Department is aware that many regulated entities have failed to implement adequate technical controls, or, in some cases, any technical controls. For example:

• A large health system that operates in multiple States experienced a massive data breach resulting from a hacking incident. OCR's investigation found indications of potential failures to sufficiently monitor its activity in its information systems that was insufficient to protect against a cyberattack, implement an authentication process to safeguard its ePHI, and have security measures in place to protect ePHI from unauthorized access when it was being transmitted electronically.^[687]

• A Rhode Island nonprofit health system experienced a data breach resulting from the theft of a laptop. OCR's investigation found indications of potential failures to encrypt ePHI, despite the entity's determination to implement encryption, and a lack of device and media controls.^[688]

• At a large covered entity, workforce members used their log-in credentials to access medical records maintained in the entity's EHR without a job-related purpose.^[689] OCR's investigation found evidence of potential violations of the requirement to implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of the Security Rule.^[690]

• At another covered entity, the potential failure to implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI, among other things, enabled a workforce member to sell the ePHI of more than 12,000 individuals.^[691]

Some investigations have found indications that regulated entities may implement technical controls that address some, but not all, users of and technology assets in a relevant electronic information system, such as software, hardware, and persons involved in the development, configuration, and implementation of technical controls.^[692] And other investigations have suggested that the potential failure of a regulated entity to have security measures in place to protect ePHI from unauthorized access when it is transmitted electronically has resulted in increased risk and breaches of ePHI.^[693] Common network segmentation practices would have substantially reduced the risk to the security ePHI and could have prevented such breaches.

Beyond the health care sector, threat actors have been able to gain access to networks by compromising user accounts and taking advantage of insufficient network segregation. For example, the 2014 Home Depot breach involved the compromise of a third-party vendor's username and password to enter Home Depot's network, which allowed hackers to obtain elevated rights to navigate to self-checkout point-of-sale system.^[694] The Department is concerned about the potential effects of such incidents in health care, where they would jeopardize the confidentiality, integrity, and availability of ePHI.

Finally, consistent with the concerns expressed above about the implications of recent caselaw and the uncertainty it might cause among regulated entities assessing whether they have adequately protected their ePHI, the Department is concerned that the existing Security Rule may not provide sufficient instruction to regulated entities about ( print page 965) how they must maintain specific security measures.

3. Proposals

The Department retains the requirements for technical safeguards generally and proposes additions and modifications to the existing standards and implementation specifications.

a. Section 164.312—Technical Safeguards

The Department proposes to expand the primary provision at 45 CFR 164.312 to clarify that regulated entities as a general matter must implement and document the implementation of technical safeguards adopted for compliance with the Security Rule. This proposal would clarify that the requirement to implement and document technical safeguards would apply to all technical safeguards, including technical controls, implemented by a regulated entity to protect the confidentiality, integrity, and availability of all ePHI it creates, receives, maintains, or transmits.

As noted above, the current provision at 45 CFR 164.312 does not reference the documentation requirements in 45 CFR 164.316. Therefore, for clarity, we propose to explicitly require in 45 CFR 164.312 that documentation of technical safeguards conforms to the requirements in 45 CFR 164.316. This proposed change would clarify that a regulated entity must document the policies and procedures required to comply with this rule and how entities considered the flexibility factors in 45 CFR 164.306(b). It would also clarify that a regulated entity must document each action, activity, and assessment required by the Security Rule. The Department considers the documentation requirements and other provisions of 45 CFR 164.316 to apply to all of the safeguards, including the technical safeguards, and this proposal is intended to remove any potential uncertainty among regulated entities. Additionally, we propose to add maintenance requirements separately to the implementation specifications for particular technical safeguards in 45 CFR 164.312, as discussed below and consistent with our proposals to add similar requirements to particular administrative and physical safeguards.

Additionally, as discussed above, the Department proposes to remove the distinction between required and addressable implementation specifications and make all implementation specifications required, with specific, limited exceptions. Also as discussed above, we propose to modify certain standards and implementation specifications to clarify that the technical safeguards apply to ensure the confidentiality, integrity, and availability of ePHI, which requires a regulated entity to implement the technical safeguards in or on all relevant electronic information systems. These proposals are discussed in greater detail below.

b. Section 164.312(a)(1)—Standard: Access Control

The Department proposes to clarify the standard for access control at 45 CFR 164.312(a)(1) by requiring a regulated entity to deploy technical controls in relevant electronic information systems to allow access only to those users and technology assets that have been granted access rights. This proposed modification would ensure that a regulated entity deploys technical controls, rather than solely ensuring that it implements technical policies and procedures, consistent with our proposals to define “deploy” and “implement.” ^[695] Thus, the proposal would clarify that a regulated entity is not expected to merely establish a policy and procedure, but must also put into place, ensure the operation of, and verify the continued operation of, technical controls for access to its relevant electronic information systems such that the failure to have such technical control in operation throughout its enterprise would be a violation of the new proposed standard. Additionally, the Department's proposal would clarify that access controls would apply to persons with authorized access and to technology assets.

Access controls are one of the key mechanisms by which a regulated entity protects ePHI. Such technical controls ensure that access to the regulated entity's electronic information systems is limited to only users and technology assets that have been granted access rights under the policies and procedures adopted in accordance with the standard for information access management under 45 CFR 164.308.^[696] The Security Rule does not identify a specific type of access control method or technology to deploy, nor are we proposing to do so in this rule.^[697] As discussed above, access rights should be role-based and the technical controls should assist the regulated entity in implementing such policies and procedures. For example, workforce members responsible for monitoring and administering a regulated entity's relevant electronic information systems, such as someone responsible for cybersecurity or providing technical support to users, must only have access to ePHI and to the regulated entity's relevant electronic information systems as appropriate for their role and job function.

We also propose at 45 CFR 164.312(a)(1) to add a paragraph heading to clarify the organization of the regulatory text.

The Department proposes to modify the existing implementation specifications under the standard for access control and to add five new implementation specifications. Additionally, we propose to redesignate the implementation specification for encryption and decryption as a standard.

We propose to modify the implementation specification for unique user identification at 45 CFR 164.312(a)(2)(i) by renaming the implementation specification as “Unique identification” and adding a requirement to assign a unique identifier for tracking each technology asset. These proposed modifications would clarify for regulated entities that the purpose of this requirement is to enable a regulated entity to identify and track unauthorized activity in its relevant electronic information systems. Such unauthorized activity may include activity by unauthorized persons or technology assets. It may also include activity by persons who are authorized to access the regulated entity's relevant information systems but who access ePHI that they do not need to access for their job or function.

The Department also proposes to expand the types of identifiers a regulated entity may assign to users and technology assets beyond names to include numbers and/or other identifiers and to clarify that a unique identifier must be assigned to each user and technology asset in the regulated entity's relevant electronic information systems. This proposed modification would better meet the goals of this implementation specification by requiring a regulated entity to be able to discern and track activities among all users and technology assets, regardless of whether that user or technology asset is a person, hardware, software program, or device. The proposed implementation specification for unique identification aligns with the Department's essential CPG for Unique Credentials, which calls for regulated entities to use unique credentials to ( print page 966) help detect and track anomalous activities.^[698]

Additionally, we propose to add an implementation specification at proposed 45 CFR 164.312(a)(2)(ii) for administrative and increased access privileges. Access controls should enable an authorized user to access the minimum necessary information needed to perform their job functions.^[699] Rights and/or privileges should be granted to authorized users based on the policies and procedures required under the administrative safeguard for information access management.^[700] For example, a workforce member who has certain role-based administrative access privileges should have separate user identities for non-administrative access privileges and administrative access privileges. Separating a single workforce member's user identities based on access privilege substantially limits the risk that an intruder will be able to access ePHI through a workforce member's user identity when they are using the administrative access privileges.^[701] A regulated entity may be able to improve the control and review of the use of administrative access privileges, such as through a privileged access management system, to understand how privileged accounts are used within its environment and help detect and prevent the misuse of privileged accounts.^[702]

The proposed implementation specification would require a regulated entity to separate the unique user identities required by the implementation specification for unique user identification based on the type of access privileges used by a specific unique user. For example, the adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to establish user permissions for accessing, and performing actions with, electronic health information based on unique identifiers may contribute to a regulated entity's compliance with the proposed new implementation specification for administrative and increased access privileges, should the proposal be finalized.^[703] This proposed new implementation specification aligns with the Department's essential CPG for Separate User and Privileged Accounts by addressing the separation of privileged or administrator access rights from common user accounts.^[704]

Additionally, the Department proposes to redesignate the implementation specification for emergency access procedures at 45 CFR 164.312(a)(2)(ii) as proposed 45 CFR 164.312(a)(2)(iii) and to modify it to require a regulated entity to establish both written procedures and technical procedures for obtaining necessary ePHI during an emergency and to implement them as needed. For example, we note that the adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to permit an identified set of users to access electronic health information during an emergency may contribute to a regulated entity's compliance with the proposed implementation specification for emergency access procedures, should the proposal be finalized.^[705]

Under the Department's proposal, the implementation specification for automatic logoff at 45 CFR 164.312(a)(2)(iii) would be redesignated as proposed 45 CFR 164.312(a)(2)(iv) and modified to require a regulated entity to deploy technical controls that terminate an electronic session after a period of inactivity. Deploying a mechanism to automatically terminate an electronic session after a period of inactivity reduces the risk of unauthorized access when a user forgets or is unable to terminate their session.^[706] Failure to deploy automatic logoff not only increases the risk of unauthorized access and potential alteration or destruction of ePHI; it also impedes an organization's ability to properly investigate such unauthorized access because it would appear to originate from an authorized user.^[707]

The Department proposes that the period of inactivity be both predetermined and reasonable and appropriate. When determining the length of the period of inactivity, a regulated entity should consider the access privileges of a given user or technology asset, the system(s) being accessed, the environment in which the system access occurs, and other appropriate factors in determining a reasonable and appropriate time of inactivity before session termination. For example, in an emergency setting, a user may not have time to manually log out of a system. User identities with administrative and other high-level access that present a greater risk to the confidentiality, integrity, and availability of ePHI should have appropriately shorter periods of inactivity because of the increased risk. While many applications have configuration settings for automatic logoff,^[708] a regulated entity must determine whether the default automatic logoff is reasonable and appropriate and make modifications if it is not. For example, the adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to automatically stop a user's access to health information after inactivity for a predetermined period and require a user to re-enter their credentials to resume or regain access may contribute to a regulated entity's compliance with the proposed implementation specification for automatic logoff, should the proposal be finalized.^[709]

Additionally, we propose to add an implementation specification for log-in attempts at proposed 45 CFR 164.312(a)(2)(v). The proposal would require a regulated entity to deploy technical controls that disable or suspend the access of a user or technology asset to relevant electronic information systems after a certain number of unsuccessful authentication attempts. Although incorrectly keying in a known password by the intended user may occur infrequently, a repeated and persistent failure is a strong indication of an attempt at unauthorized access. For example, brute force attacks are attempts to gain unauthorized access by guessing the password many times in a row.^[710] Technical controls that limit the number of incorrect log-in attempts by disabling or suspending the access of a user or technology asset to relevant electronic information systems are appropriate to address unsuccessful login attempts.^[711]

The proposal would require a regulated entity to determine the number of unsuccessful authentication attempts that would trigger disabling or suspending access to relevant electronic information system. The number should ( print page 967) be reasonable and appropriate for the type of user or technology asset, the electronic information system or technology asset to which access is sought, and the type of information maintained on such information system or technology asset. For example, a regulated entity may determine that any authentication failure of an administrative privileged access account should disable the account because of the level of risk compared to an authentication failure of a non-administrative privileged account. The Department does not propose to define disable or suspend and relies upon the industry understanding that disabling a user's access would require intervention to restore the capability to use the user identity, while a suspension may prevent additional log-in attempts for a temporary, limited period of time.

Consistent with NCVHS' recommendation and existing guidance, the Department also proposes to add an implementation specification for network segmentation at 45 CFR 164.312(a)(2)(vi) that would require a regulated entity to deploy technical controls to segment its relevant electronic information systems in a reasonable and appropriate manner.^[712] Under this proposal, a regulated entity with multiple, distinct electronic information systems would be required to separate relevant electronic information systems using reasonable and appropriate technical controls. Network segmentation is a physical or virtual division of a network into multiple segments, creating boundaries between the operational and IT networks to reduce risks, such as threats caused by phishing attacks.^[713] For example, where a regulated entity operates both a point-of-sale system and an EHR on the same network, the EHR could be compromised through a successful attack by an intruder moving laterally ( i.e., within the same network) from a previously compromised point-of-sale system because the intruder's movements were not impeded by network segmentation. Accordingly, we believe that it is appropriate to require regulated entities to deploy technical controls to segment the networks to which their relevant electronic information systems are connected.^[714] What constitutes reasonable and appropriate network segmentation depends on the regulated entity's risk analysis and how it has implemented its network(s) and relevant electronic information systems. This proposed new implementation specification aligns with the Department's enhanced CPG for Network Segmentation because where the CPG is implemented, an intruder's ability to freely move within a regulated entity's network and protect ePHI is minimized.^[715]

The proposed implementation specification for data controls at proposed 45 CFR 164.312(a)(2)(vii) would require a regulated entity to deploy technical controls to allow access to ePHI based on the regulated entity's policies and procedures for granting users and technology assets access relevant electronic information systems as specified in proposed 45 CFR 164.308(a)(10). This implementation specification would require a regulated entity to have in place technical controls that distinguish between users and technology assets, that are permitted to access the regulated entity's relevant electronic information systems and those that are not permitted to do so and would require that the controls permit or disallow access accordingly.

Properly deployed network-based solutions can limit the ability of a hacker to gain access to an organization's network or impede the ability of a hacker already in the network from accessing other electronic information systems—especially systems containing sensitive data.^[716] Access controls could include role-based access, user-based access, or any other access control mechanisms the organization deems appropriate.^[717] Access controls need not be limited to computer systems—firewalls, network segmentation, and network access control solutions are effective means of limiting access to relevant electronic information systems.^[718]

Additionally, we propose to add an implementation specification for maintenance at proposed 45 CFR 164.312(a)(2)(viii). Under this proposal, a regulated entity would be expressly required to review and test the effectiveness of the procedures and technical controls required by the implementation specifications associated with the standard for access control at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

c. Section 164.312(b)(1)—Standard: Encryption and Decryption

Encryption can reduce the risks and costs of unauthorized access to ePHI.^[719] For example, if a hacker gains access to unsecured ePHI on a network server or if a device containing unsecured ePHI is stolen, a breach of PHI will be presumed and reportable under the Breach Notification Rule.^[720] The Breach Notification Rule applies to unsecured PHI, which is PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in guidance issued under the HITECH Act.^[721] The Department's guidance on rendering unsecured PHI unusable, unreadable, or indecipherable to persons who are not authorized to access such PHI states that ePHI at rest ( i.e., stored in an information system or electronic media) is considered secured if it is encrypted in a manner consistent with NIST Special Publication 800-111 ^[722] (“SP 800-111”). The ePHI encrypted in a manner consistent with SP 800-111 is not considered unsecured PHI and therefore qualifies for what is commonly known as the Breach Notification safe harbor, meaning that it is not subject to the requirements of the Breach Notification Rule.^[723] Thus, by encrypting ePHI in a manner consistent with the Secretary's guidance, a regulated entity may not only fulfill its encryption obligation under the Security Rule, but also make use of the ( print page 968) Breach Notification Rule's safe-harbor provision.^[724]

As the use of mobile computing devices ( e.g., laptops, smartphones, tablets) has become more pervasive, the risks to sensitive data stored on such devices also have increased.^[725] And while in 2003 and even in 2013, encryption might have been out of reach for many regulated entities because of cost or a similar reason,^[726] today, encryption solutions are generally considered to be widely accessible. The cost of such solutions has decreased significantly, as has the difficulty in implementing such solutions. In fact, many applications have encryption solutions embedded in them.^[727] Once enabled, a device's encryption solution can protect stored sensitive data, including ePHI, from unauthorized access in the event the device is lost or stolen. The same is true for most software today.^[728] Thus, while encryption of a particular regulated entity's ePHI might not have been reasonable and appropriate in 2003 or 2013, the Department believes encryption generally is reasonable and appropriate today.^[729]

Because the prevalence of encryption solutions has increased, as has their affordability and the role they play in protecting information, including ePHI, the Department believes it is appropriate to consider requiring encryption and elevating it from an implementation specification to a standard to increase its visibility and prominence. Based on this and consistent with NCVHS' recommendation, the Department proposes to redesignate the implementation specification for encryption and decryption at 45 CFR 164.312(a)(2)(iv) as a standard at proposed 45 CFR 164.312(b)(1).^[730] The proposed standard would incorporate the requirements of two implementation specifications that address encryption—the one addressed here and the one at 45 CFR 164.312(e)(2)(ii).^[731] The Department proposes that the new standard would require a regulated entity to configure and implement technical controls to encrypt and decrypt all ePHI in a manner that is consistent with prevailing cryptographic standards. This proposed new standard aligns with the Department's essential CPG for Strong Encryption by calling for regulated entities to deploy encryption to protect ePHI and with the recommendation of NCVHS.^[732] We also note that the adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to encrypt and decrypt electronic health information, using an encryption algorithm that meets certain requirements, may contribute to a regulated entity's compliance with the proposed standard for encryption and decryption, should the proposal be finalized.^[733]

Under the proposal, a regulated entity would need to ensure that an encryption solution that it adopts meets prevailing cryptographic standards prior to using it. The Department uses the phrase “prevailing cryptographic standards” to refer to widely accepted standards for encryption and decryption that are recommended by authoritative sources and that ensure the confidentiality, integrity, and availability of ePHI at the time the regulated entity performs its risk analysis and establishes or modifies its risk management plan. The Department would expect a regulated entity to deploy updated encryption solutions as prevailing cryptographic standards evolve, consistent with both of the proposed requirements discussed above: (1) to review, verify, and update its risk analysis in response to changes in its environment that may affect ePHI; and (2) to review and modify, as reasonable and appropriate, its risk management plan in response to changes in its risk analysis. Thus, a regulated entity using an encryption algorithm that is known to be insecure would not be in compliance with the proposed requirement to deploy an encryption algorithm that meets prevailing cryptographic standards. We are not proposing to define prevailing cryptographic standards in regulatory text at this time.

The Department proposes to add one implementation specification for the proposed standard for encryption and decryption. Specifically, proposed 45 CFR 164.312(b)(2) would require regulated entities to encrypt all ePHI at rest and in transit, with limited exceptions.^[734] Thus, a regulated entity would be required to encrypt all ePHI it maintains, as well as all ePHI it transmits, unless an exception applies, and the following conditions are met:

• Each exception applies only to the ePHI directly affected by the circumstances described in the specific exception.
• Each exception applies only to the extent that the regulated entity documents its understanding that the exception applies to the scenario in which the regulated entity relies upon the exception and why or how the exception applies, and that any additional applicable conditions are met.

The first proposed exception at proposed 45 CFR 164.312(b)(3)(i) would apply to a technology asset currently used by a regulated entity that does not support encryption according to prevailing cryptographic standards. Because the requirements for encryption under the Security Rule today are addressable, a regulated entity may be in compliance with the encryption requirement without actual encryption of ePHI if encryption is not reasonable and appropriate, provided that the entity meets certain conditions. Additionally, technology assets in use today may rely on cryptographic standards that are no longer accepted industry practice. The Department recognizes that it may take some time for a regulated entity to adopt compliant technology assets. Thus, we propose this exception for such technology assets that do not support encryption consistent with prevailing cryptographic standards in limited circumstances. Specifically, to meet this exception, a regulated entity would be required to establish a written plan to migrate ePHI to technology assets that support encryption consistent with prevailing cryptographic standards and to implement such plan. The regulated entity would be required to establish and implement the written plan within ( print page 969) a reasonable and appropriate period of time. For example, it would not be reasonable or appropriate for a regulated entity to establish a plan to migrate ePHI on a single flash drive within 30 days and not complete migration of that ePHI for a period of a year because migrating ePHI from a flash drive to a more secure medium is a simple and quick process that the regulated entity already determined could be completed within 30 days. Thus, a year would be an unreasonably long period to leave ePHI insufficiently encrypted, particularly after a need to migrate the ePHI has been established. In such circumstances, the regulated entity would not be complying with the requirements of this proposed exception.

The second proposed exception at proposed 45 CFR 164.312(b)(3)(ii) would be available for ePHI transmitted in response to an individual request, pursuant to 45 CFR 164.524, to receive their ePHI in an unencrypted manner. Unencrypted manners for an individual to receive their ePHI may include some types of text messaging, instant messaging, and other applications on a smartphone or another computing device that are capable of making an access request and receiving ePHI.^[735] This exception for individual access requests under 45 CFR 164.524 would not apply when the individual would receive their ePHI using technology controlled by the regulated entity, such as a patient portal ^[736] or other technology for the transmission of ePHI ( e.g., API technology).^[737] Such email or messaging technologies are considered to be among a covered entity's technology assets because they are components of a covered entity's relevant electronic information systems, and the requirement to encrypt ePHI would apply.

Under the right of access, an individual who is the subject of PHI has the right to inspect and request a copy of PHI about them in a designated record set, subject to certain exceptions. A regulated entity is required to provide such access in the form and format requested by the individual, if it is readily producible in such form and format. Thus, if an individual requests that the regulated entity provide them access in a manner that does not support encryption, a regulated entity is generally required to do so if it does not jeopardize the security of the regulated entity's information systems. For the exception to apply, a regulated entity would be required to have informed the individual of the risks associated with the transmission, receipt, and storage of unencrypted ePHI when the individual requests unencrypted access and to document that the individual has been informed of such risks.^[738]

Consistent with the information blocking regulations, the information provided by regulated entities that are also actors must: focus on any current privacy and/or security risks posed by the technology or the third-party developer of the technology; be factually accurate, unbiased, objective, and not unfair or deceptive; and be provided in a non-discriminatory manner.^[739] For example, a regulated entity that is an actor must provide information to individuals about the privacy and security risks of all mobile health applications in the same manner.

We are not proposing to require that the documentation be in any particular form or format. Rather, the required information could be on a standard form, chart note, or checkbox, as examples. The Department does not propose to apply this exception to ePHI transmitted in other forms or formats, such as on a CD or other physical device used to maintain and transmit ePHI. The proposal would not absolve a regulated entity from compliance with other applicable laws or regulations, including the information blocking regulations.^[740]

We recognize that emergencies or other occurrences may render it infeasible to encrypt ePHI. Thus, the third proposed exception at 45 CFR 164.312(b)(3)(iii) would apply to certain circumstances in which encryption is infeasible. Such circumstances would be limited to when there is emergency or other occurrence that adversely affects a regulated entity's relevant electronic information systems. For the proposed exception to apply, a regulated entity would be required to implement reasonable and appropriate compensating controls in accordance with and determined by its contingency plan.^[741] The Department would expect this proposed exception to be applicable for a limited period of time and only when encryption is infeasible. As noted above, the proposed exception to encryption would narrowly apply only when a regulated entity's relevant electronic information system is adversely affected by the emergency or other occurrence. The proposed exception would no longer be applicable at such time encryption becomes feasible, regardless of whether the emergency or other occurrence continues.

The fourth proposed set of exceptions at proposed 45 CFR 164.312(b)(3)(iv) would be for ePHI that is created, received, maintained, or transmitted by a medical device ( i.e., a “device” within the meaning of section 201(h) of the Federal Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h)) that is authorized by the FDA for marketing. We propose three separate exceptions for devices that are authorized by the FDA for marketing pursuant to: a submission received before March 29, 2023; a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer; or a submission received on or after March 29, 2023, where the device is supported by its manufacturer. Where a device has been authorized by the FDA for marketing pursuant to a submission received before March 29, 2023, we propose that the exception at proposed 45 CFR 164.312(b)(3)(iv)(A) would be available only where the regulated entity deploys in a timely manner any updates or patches required or recommended by the manufacturer of the device. We also propose a similar exception at proposed 45 CFR 164.312(b)(3)(iv)(B) for devices authorized by the FDA for marketing pursuant to a submission received on or ( print page 970) after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the regulated entity has deployed any updates or patches required or recommended by the manufacturer.

We recognize that, to comply with this proposal, some regulated entities may incur costs for replacing legacy medical devices ( i.e., medical devices that cannot be reasonably protected against current cybersecurity threats).^[742] We also recognize that legacy devices can pose significant risks to the confidentiality, integrity, and availability of ePHI.^[743] By limiting these exceptions to devices that have been updated and/or patched while they were supported by their manufacturer, we believe that this proposal would balance the interest in encouraging regulated entities to dispense with legacy devices with the cost of replacing such devices. Additionally, the Department believes that regulated entities should already have plans to replace legacy devices that cannot be made cybersecure because of their existing Security Rule obligations. We also recognize that at some point, most, if not all, devices will likely become legacy devices and that there may be legitimate reasons not to immediately replace them when the manufacturer ceases to provide support. In such cases, it will continue to be important for regulated entities to plan for how to address their ongoing Security Rule obligations.

Finally, we propose an exception, proposed 45 CFR 164.312(b)(3)(iv)(C), that would be available for a device authorized by the FDA for marketing pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer. We understand that the FDA considers security during the review of medical device marketing submissions, including those for software that is approved as a medical device, and works with device manufacturers to ensure that appropriate cybersecurity protections are built into such devices, pursuant to FDA's authority under the Consolidated Appropriations Act, 2023.^[744] Thus, we do not believe it would be necessary or appropriate for the Security Rule to require encryption for an FDA-authorized medical device that has been authorized by the FDA for marketing pursuant to a submission received on or after March 29, 2023 where the device continues to be supported by its manufacturer.

Where a proposed exception applies to the proposed encryption requirement, the Department also proposes to require that a regulated entity implement alternative measures and compensating controls. Specifically, we propose at proposed 45 CFR 164.312(b)(4)(i) to require a regulated entity to document the existence of an applicable exception and implement reasonable and appropriate compensating controls. Under the proposal, we would require documentation to occur in real-time, meaning when the criteria for the exception exist and at the time compensating controls are implemented. For example, a regulated entity disclosing ePHI to an individual by unencrypted email in accordance with the right of access would be required to document in accordance with the proposed 45 CFR 164.312(b)(4)(i) that: (1) before the disclosure, the individual has requested to receive ePHI by unencrypted email or unencrypted messaging technology; and (2) before the disclosure, the regulated entity informed the individual of the risks associated with transmission of unencrypted ePHI. The exception would not apply where such individual requests to receive access to their ePHI pursuant to 45 CFR 164.524 via email or messaging technologies implemented by the covered entity.

At proposed 45 CFR 164.312(b)(4)(i), the Department proposes to require that where a proposed exception applies, a regulated entity would also be required to implement an alternative measure or measures that are reasonable and appropriate compensating controls under proposed 45 CFR 164.312(b)(4)(ii). Compensating controls would be implemented in the place of encryption to protect ePHI from unauthorized access.^[745] The Department does not propose to require that compensating controls be limited to technical controls. Rather, a regulated entity should consider the nature of the exception, operating environment, and other appropriate circumstances to determine what controls are reasonable and appropriate and implement compensating controls effective for those circumstances. For example, a regulated entity may use physical access controls, such as physically limiting access to a device, in combination with other controls to compensate for the absence of encryption.

Proposed paragraph (b)(4)(ii)(A) would require that if the regulated entity has determined that an exception applies, it must secure ePHI by implementing reasonable and appropriate compensating controls that are reviewed and approved by the regulated entity's designated Security Official. Because exceptions are a departure from the Security Rule framework, the Department proposes to ensure appropriate focus and review by the Security Official of the controls chosen to compensate for the absence of encryption.

With respect to the exception at proposed 45 CFR 164.312(b)(3)(iv)(C), the Department proposes at paragraph (b)(4)(ii)(B) to presume that a regulated entity had implemented reasonable and appropriate compensating controls where the regulated entity has deployed the security measures prescribed and as instructed by the FDA-authorized label for the device. This would include any updates, including patches recommended or required by the manufacturer of the device. The proposed language recognizes that while the device's label may not specifically require deployment of an encryption solution, it may provide for a specific compensating control and the manner in which that control is to be implemented. While not required, a regulated entity would be permitted to implement additional alternative security measures and compensating controls in accordance with best practices and/or its risk analysis.

Finally, at proposed paragraph (b)(4)(ii)(C), the Department proposes to require that the regulated entity's Security Official review and document the implementation and effectiveness of the compensating controls during any period in which such compensating controls are in use to continue securing ePHI and relevant electronic ( print page 971) information systems. While regulated entities should review deployed compensating controls on a routine basis, the Department proposes to require a regulated entity to periodically review the implementation and effectiveness of compensating controls to ensure the continued protection of ePHI.^[746] For example, if a regulated entity's plan to migrate ePHI from hardware that does not support encryption changes such that the use of the unencrypted hardware continues for a longer period of time, the regulated entity should review implemented compensating controls to ensure ongoing effectiveness and whether new compensating controls should be deployed. We propose to require the designated Security Office conduct such review at least once every 12 months or in response to environmental or operational changes, whichever is more frequent. Additionally, the Department proposes to require that the review be documented in writing and signed. If the regulated entity's Security Official review determines that certain compensating controls are no longer effective, the Department expects that the regulated entity would adopt new compensating controls that are effective to continue to meet the applicable exception. For example, a regulated entity would be expected to update any compensating controls for use of an FDA-authorized medical device when and as instructed by the manufacturer of the device.

We also propose to add an implementation specification for maintenance at proposed 45 CFR 164.312(b)(5). Under this proposal, a regulated entity would be expressly required to review and test the effectiveness of the technical controls required by the standard for encryption at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate. This proposal is consistent with others in this NPRM that would require regulated entities to maintain specified administrative, physical, and technical safeguards.

d. Section 164.312(c)(1)—Standard: Configuration Management

The Department believes that the failure to configure technical controls appropriately and to establish and maintain secure baselines for relevant electronic information systems and technology assets in its relevant electronic information systems presents an opportunity for cyberattack and compromise of ePHI.^[747] Accordingly, we propose to add a standard for configuration management at proposed 45 CFR 164.312(c)(1). The proposed standard would require a regulated entity to establish and deploy technical controls for securing relevant electronic information systems and technology assets in its relevant electronic information systems, including workstations, in a consistent manner. Under this proposal, a regulated entity also would be required to establish a baseline ( i.e., minimum) level of security for each relevant electronic information system and technology asset in its relevant electronic information systems and to maintain such information systems and technology assets according to those secure baselines. Consistent with our proposals regarding risk analysis and risk management planning, the Department intends for a regulated entity to establish its security baseline and to maintain that baseline even when technology changes. For example, a regulated entity that uses software to access ePHI would be required to update the software with patches as reasonable and appropriate. But where a developer ceases to support a software, it would be reasonable and appropriate for the regulated entity to take steps to either replace it or to otherwise ensure that its level of security remains consistent with the regulated entity's established baseline. Under this proposal, if finalized, the Department would expect a regulated entity to continually monitor its relevant electronic information systems and technology assets in its relevant electronic information systems to ensure that the secure baselines established by the regulated entity are maintained and take appropriate actions when a relevant electronic information system or technology asset in a relevant electronic information system fails to meet the established baselines. A regulated entity's secure baselines would be determined based on its risk analysis and use of security settings that are consistent across its relevant electronic information systems and technology assets in its relevant electronic information systems. For example, the risk analysis may determine that a manufacturer's default settings for a particular technology asset are insufficient. Accordingly, the regulated entity may establish the baseline for settings that should be applied to the particular asset and similar technologies across the regulated entity's enterprise. This proposed standard aligns with the Department's enhanced CPG for Configuration Management, which calls for regulated entities to define secure device and system settings. It also aligns with the enhanced CPG for Detect and Respond to Relevant Threats and Tactics, Techniques, and Procedures by calling for regulated entities to include malware protection in their security baseline to detect threats and protect electronic information systems.^[748] Additionally, the proposed standard also aligns with the Department's essential CPG for Email Security, which addresses the reduction of risks from email-based threats.^[749]

The Department proposes five implementation specifications for the proposed standard for configuration management.^[750] Under the proposed implementation specification for anti-malware protection at proposed 45 CFR 164.312(c)(2)(i), a regulated entity would be required to deploy technology assets and/or technical controls that protect all of the technology assets in its relevant electronic information systems against malicious software, such as viruses and ransomware. Anti-malware software, especially when used in combination with other technical controls such as intrusion detection/prevention solutions, can also help prevent, detect, and contain cyberattacks.^[751] This protection would be applied to all of a regulated entity's technology assets in its relevant electronic information systems. When determining how to fulfill this proposed obligation, regulated entities may consider deploying tools such as anti-malware and endpoint detection and response (EDR) solutions. Anti-malware tools generally scan a regulated entity's electronic information systems to ( print page 972) identify malicious software.^[752] Such tools may also quarantine malicious software if identified. As explained by the Office of Management and Budget, “EDR combines real-time continuous monitoring and collection of endpoint data [. . .] with rules-based automated response and analysis capabilities.” ^[753]

We propose a new implementation specification for software removal at proposed 45 CFR 164.312(c)(2)(ii) to require a regulated entity to remove extraneous software from the regulated entity's relevant electronic information systems. Software is extraneous if it is unnecessary for the regulated entity's operations. It can be a target for attack, and older applications may no longer be supported with patches for new vulnerabilities.^[754] Removal of unnecessary software reduces an avenue of attack. The Department is not proposing to specify what would constitute necessary and unnecessary software. Rather, we intend that the regulated entity would consider removal of unwanted or unused software, for example, default software added by a computer manufacturer or reseller where such software may open an avenue for unnecessary risk because the regulated entity does not intend to use it. Accordingly, the proposal would require a regulated entity to consider all software on its relevant electronic information systems and any potential avenue of risk and address the risk through software removal where such software is unnecessary for the regulated entity's operations.

The proposed implementation specification for configuration at proposed 45 CFR 164.312(c)(2)(iii) would require a regulated entity to configure and secure operating systems and software in a manner consistent with the regulated entity's risk analysis. Generally, a regulated entity's risk analysis should guide its implementation of appropriate technical controls to reduce the risk to ePHI.^[755] Requiring operating systems and software to be maintained in a secure manner would reduce exploitable vulnerabilities.^[756] Often, known vulnerabilities can be mitigated by applying vendor patches or upgrading to a newer version.^[757]

Under the proposed implementation specification for network ports at proposed 45 CFR 164.312(c)(2)(iv), a regulated entity would be required to disable network ports in accordance with the regulated entity's risk analysis.^[758] Successful ransomware deployment often depends on the exploitation of technical vulnerabilities such as unsecured ports.^[759] The proposal to require network ports to be disabled in accordance with the risk analysis would reduce exploitable vulnerabilities.^[760]

Lastly, the proposed implementation specification for maintenance at proposed 45 CFR 164.312(c)(2)(v) would expressly require a regulated entity to review and test the effectiveness of the technical controls required by the other implementation specifications associated with the standard for configuration management at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

e. Section 164.312(d)(1)—Standard: Audit Trail and System Log Controls

Audit controls are crucial technical safeguards that are useful for recording and examining activity in electronic information systems, especially when determining whether a security violation occurred.^[761] A regulated entity must consider its risk analysis and organizational factors, such as current technical infrastructure, hardware, and software security capabilities, to determine reasonable and appropriate audit controls.^[762] However, based on OCR's enforcement experience, we believe that regulated entities' understanding of and compliance with this standard could be improved by providing more specificity.

Accordingly, the Department proposes to redesignate the standard for audit controls at 45 CFR 164.312(b) as proposed 45 CFR 164.312(d)(1), rename it as the standard for audit trail and system log controls, and to add a paragraph heading to clarify the organization of the regulatory text. We also propose to modify it to require a regulated entity to deploy either or both technology assets and technical controls that record and identify activity in the regulated entity's relevant electronic information systems. The proposal would replace “procedural mechanisms” with “technical controls,” to match the general focus on technical controls in 45 CFR 164.312 and would recognize that a regulated entity may be able to meet the requirements of the standard by deploying either or both technology assets ( e.g., software) or technical controls. Under the proposal, a regulated entity would be required to collect sufficient information to understand what a specific activity in its relevant electronic information systems is, such that the regulated entity would be better able to address activity that presents a risk to the confidentiality, integrity, or availability of ePHI. For example, a regulated entity should understand that a given activity in a relevant electronic information system is an attempt to access a portable workstation without authorization. The proposal also would modify the limitation on the regulated entity's obligation to record and identify activity in its relevant electronic information systems. Thus, the proposal would require a regulated entity to record and identify any activity that could present a risk to ePHI, meaning activity in all of its relevant electronic information systems, not only in its electronic information systems that create, receive, maintain, or transmit ePHI. In so doing, the Department would also require a regulated entity to record and identify activity in its electronic information systems that may affect the confidentiality, integrity, or availability of ePHI. This redesignated standard, as proposed, aligns more closely with the Department's enhanced CPG for Centralized Log Collection by addressing the deployment of technical controls to record and identify activity in all electronic information systems.^[763] Additionally, as an example, we note that adoption of health IT certified through the ONC Health IT Certification Program may contribute to a regulated entity's compliance with the proposed standard for audit trail and system log controls where such health IT meets the criteria for auditing actions on health information and recording actions related to electronic health information and audit log status.^[764]

( print page 973)

The Department proposes four implementation specifications under this proposed standard that are intended to improve the effectiveness of audit controls deployed by a regulated entity. The proposed implementation specification for monitoring and identifying activity at proposed 45 CFR 164.312(d)(2)(i) would require a regulated entity to deploy technology assets and/or technical controls that monitor in real-time ( i.e., contemporaneously) all activity occurring in a regulated entity's relevant electronic information systems and identify indications of unauthorized persons and unauthorized activity, as determined by the regulated entity's risk analysis. As proposed, the technology assets and/or technical controls also would be required to alert workforce members of such indications in accordance with the regulated entity's policies and procedures for information system activity review at proposed 45 CFR 164.308(a)(7). Unauthorized activity may include actions by technology assets or persons that have not been authorized to access the regulated entity's ePHI or relevant electronic information systems. It may also include actions by authorized users or technology assets that are inconsistent with the regulated entity's policies and procedures for information access management at proposed 45 CFR 164.308(a)(10). The Department proposes that monitoring be continual and conducted in real-time because asynchronous review would allow for the compromise of ePHI for the period of time between the unauthorized activity and its discovery. OCR's enforcement experience has shown that some regulated entities are potentially failing to implement appropriate audit controls or to review information system activity in a timely manner, which may have contributed to a reportable breach.^[765]

A regulated entity would be required, under the proposed implementation specification for recording activity at proposed 45 CFR 164.312(d)(2)(ii), to deploy technology assets and/or technical controls that record in real-time all activity in the regulated entity's relevant electronic information systems.^[766] While technical assets and/or technical controls deployed in accordance with proposed 45 CFR 164.312(d)(2)(i) would monitor activity in its relevant electronic information systems, recording such activity would enable a regulated entity to assess any activity to better understand the activity's effects. The proposed implementation specification at proposed 45 CFR 164.312(d)(2)(iii) would require a regulated entity to deploy technology assets and/or technical controls to retain records of all activity in its relevant electronic information systems as determined by the regulated entity's policies and procedures for information system activity review at 45 CFR 164.308(a)(7)(ii)(A). The proposed implementation specification for scope of activity at proposed 45 CFR 164.312(d)(2)(iv) would clarify what would constitute activity to be monitored and recorded in the regulated entity's relevant electronic information systems as required by the proposed implementation specifications at proposed 45 CFR 164.312(d)(2)(i) and (ii). Specifically, the Department proposes that such activities would include, but would not be limited to, creating, accessing, receiving, transmitting, modifying, copying, or deleting ePHI; and creating, accessing, receiving, transmitting, modifying, copying, or deleting relevant electronic information systems and the information ( i.e., not only ePHI) therein.

We also propose to add an implementation specification for maintenance at proposed 45 CFR 164.312(d)(2)(iv). Under this proposal, a regulated entity would be expressly required to review and test the effectiveness of the technology assets and/or technical controls required by the respective implementation specifications of this section at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

f. Section 164.312(e)—Standard: Integrity

Improper alteration or destruction of ePHI, even unintentionally, can result in clinical quality problems, including patient safety issues, for a covered entity.^[767] Workforce members or business associates may make accidental or intentional changes that improperly alter or destroy ePHI.^[768] Data can also be altered or destroyed without human intervention, such as by electronic media errors or failures.^[769] It is important to protect ePHI from being compromised, regardless of the source.^[770]

The current standard for integrity at 45 CFR 164.312(c)(1) requires implementation of policies and procedures, rather than actual deployment of technical controls, to ensure integrity of ePHI. To improve the effectiveness of this standard, the Department proposes to redesignate it as proposed 45 CFR 164.312(e) and modify it for clarity. Under the proposal, a regulated entity would be required to deploy technical controls to protect ePHI from improper alteration or destruction when at rest and in transit and to review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate. For example, the adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to verify that the electronically exchanged health information contained within the health IT has not been altered, using a hashing algorithm that meets certain requirements, may contribute to a regulated entity's compliance with the proposed standard for integrity.^[771] The Department proposes to remove the implementation specification at 45 CFR 164.312(c)(2) because technical controls to corroborate that ePHI has not been altered or destroyed in an unauthorized manner are commonly built into hardware and protocols today. Thus, it is unnecessary to require a regulated entity to specifically deploy such controls.

g. Section 164.312(f)(1)—Standard: Authentication

Authentication ensures that a person is in fact who they claim to be before being allowed access to ePHI by providing proof of identity.^[772] The Department proposes to redesignate the standard for person or entity authentication at 45 CFR 164.312(d) as 45 CFR 164.312(f)(1) to rename it “Authentication” to reflect its broad purpose, and to add a paragraph heading to clarify the organization of the regulatory text. Additionally, consistent with our proposals to define ( print page 974) “implement” and “deploy,” we propose to replace the requirement for a regulated entity to implement procedures with a requirement to deploy technical controls. Also, consistent with our proposals to clarify that a regulated entity's obligations to ensure the confidentiality, integrity, and availability extend to all of its relevant electronic information systems, we propose to clarify that the regulated entity is to deploy technical controls to verify that a person seeking access to the regulated entity's relevant electronic information systems is the one claimed. The Department also proposes to modify the existing standard to clarify that a regulated entity would be required to deploy technical controls to verify that a technology asset seeking access to the regulated entity's relevant electronic information systems is the one claimed. Thus, the proposed standard for authentication would require a regulated entity to deploy technical controls to verify that a person or technology asset seeking access to ePHI and/or the regulated entity's relevant electronic information systems is, in fact, the person or technology asset that the person or asset claims to be. We also propose to remove the reference to an entity because entity is included within the definition of person.

The Department proposes four implementation specifications under this standard. Consistent with NCVHS' recommendation to eliminate the use of default passwords, the proposed implementation specification for information access management policies at proposed 45 CFR 164.312(f)(2)(i) would require a regulated entity to deploy technical controls in accordance with its information access management policies and procedures, including technical controls that require users to adopt unique passwords.^[773] Among other things, this proposal would ensure that regulated entities change default passwords. Such unique passwords would be required to be consistent with current recommendations of authoritative sources. The Department does not propose to define authoritative sources and defers to best practices for setting and maintaining passwords of sufficient strength to ensure the confidentiality, integrity, and availability of ePHI. Under this proposal, a regulated entity would need to require its workforce members to change any default passwords to unique passwords that are consistent with current authoritative source recommendations for unique passwords, as well as prevent the sharing of passwords among workforce members. Default passwords, typically factory-set passwords, may be discovered in common product documentation and used by attackers to gain access to relevant electronic information systems.^[774] Thus, the Department believes that it is crucial for the security of ePHI that a regulated entity eliminate the use of default passwords.

In addition to proposing the elimination of default passwords, the Department proposes a specific requirement for a regulated entity to deploy MFA in the implementation specification for MFA at proposed 45 CFR 164.312(f)(2)(ii). We propose to expressly require MFA, as recommended by NCVHS, because it increases security by ensuring that a compromise of a single credential does not allow access to unauthorized users.^[775] MFA is an effective way to reduce the risk of brute force attacks and to increase the cost of such attack, making such an attack less appealing to intruders.^[776] Further, deployment of MFA aligns with the Department's essential CPGs for Email Security and Multifactor Authentication because use of MFA would be applicable to email access and protect assets connected to the internet.^[777] Accordingly, proposed 45 CFR 164.312(f)(2)(ii)(A) would require a regulated entity to deploy MFA to all technology assets in its relevant electronic information systems to verify that the person seeking access to its relevant electronic information system is the user that the person claims to be. A regulated entity should deploy MFA to all technology assets in its relevant electronic information systems in a manner consistent with its risk analysis. MFA allows for the use of different categories of factors as described earlier. A decision by a regulated entity to use specific factors during specific circumstances where MFA is deployed will be dependent upon the risks to ePHI identified by the regulated entity and the ability of technology to use such factors to authenticate specific users. For example, certain behavioral characteristics may not satisfy current standards for MFA; however, the Department anticipates that it may be reasonable and appropriate in the future for a regulated entity to adopt a solution where users provide such characteristics as one of the factors. Additionally, a regulated entity may identify varying levels of risk posed by its technology assets and elect to deploy MFA in different ways to address the risk posed by each asset. For example, consistent with its risk analysis, a regulated entity may choose to deploy a single sign-on (SSO) authentication solution using MFA to allow users to access multiple local applications, while also requiring users to authenticate using MFA to access certain cloud-based services.

This proposed implementation specification generally is consistent with ASTP/ONC's “Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability” (HTI-2) NPRM's proposed revisions to the MFA criterion requiring certified health IT to support authentication, through multiple elements, of the user's identity, according to today's standards such as those recommended by NIST, and enable user to configure, enable, and disable the MFA capabilities.^[778] Adoption of health IT that is certified through the ONC Health IT Certification Program as meeting the proposed MFA criterion, should the proposal be finalized, may contribute to a regulated entity's compliance with the proposed implementation specification for MFA in this NPRM.

Under proposed 45 CFR 164.312(f)(2)(ii)(B), a regulated entity would be required to deploy MFA for any action that would change a user's privileges to the regulated entity's relevant electronic information systems in a manner that would alter the user's ability to affect the confidentiality, integrity, or availability of ePHI. These modified privileges may provide a user with a level of access inconsistent with a regulated entity's policies and procedures and increase the risk to ePHI by affording a user who does not need to have access to certain systems or information the opportunity to remove security measures deployed to protect ePHI. Because a user may affect the confidentiality, integrity, or availability of ePHI by accessing a relevant electronic information system, a regulated entity would be expected to ( print page 975) deploy MFA for changed privileges in both types of systems.

Similar to the proposed standard for encryption, the Department proposes three exceptions at proposed 45 CFR 164.312(f)(2)(iii) to the proposed specific requirement to implement MFA. The first proposed exception at proposed 45 CFR 164.312(f)(2)(iii)(A) would be for a technology asset that does not support MFA but is currently in use by a regulated entity. Because the requirements for authentication under the existing Security Rule today do not expressly refer to MFA, a regulated entity that is not using MFA to meet the requirement to authenticate user identities may argue that it is in compliance with the authentication standard without using MFA. The Department recognizes that it may take some time for a regulated entity to adopt compliant software or hardware, and thus we propose an exception where such software or hardware does not support MFA. To meet this exception, a regulated entity would be required to establish a written plan to migrate ePHI to technology assets that supports MFA and to actually migrate the ePHI to such technology assets in accordance with the written plan. Accordingly, a regulated entity would be required to establish the plan, implement the plan, and actually migrate ePHI to technology assets that supports MFA within a reasonable and appropriate period of time. For example, it would not be reasonable and appropriate for a regulated entity to establish a plan to migrate to a new practice management system that supports MFA and fail to take any steps to perform the migration for an entire year. Applying the standard flexibly and at scale, a reasonable and appropriate timeframe for a system with 5,000 users may be different than one for a solo practitioner; however, both entities would be expected to progress to completion.

We recognize that emergencies or other occurrences may render it infeasible for a regulated entity to use MFA, so we propose a second exception for when MFA is infeasible during an emergency or other occurrence that adversely affects the regulated entity's relevant electronic information systems or the confidentiality, integrity, or availability of ePHI.^[779] For the proposed exception to apply, a regulated entity would be required to implement reasonable and appropriate compensating controls in accordance with its contingency plan ^[780] and emergency access procedures.^[781] For example, if an optical scanner used by a regulated entity as one of the required factors for MFA is rendered inoperable ( e.g., is temporarily broken or adversely affected by a cyberattack), a compensating control may be to temporarily allow users to log in with their user name and a unique password, rather than with a PIN and retinal scan. The Department would make this proposed exception applicable only for the limited period of time in which MFA is infeasible for the regulated entity during the emergency or other occurrence, regardless of whether the emergency or other occurrence continues.

At proposed 45 CFR 164.312(f)(2)(iii)(C), we propose three exceptions that would be for a technology asset in use that is a device within the meaning of section 201(h) of the Food, Drug, and Cosmetic Act that has been authorized for marketing by the FDA. The first would be for a device authorized by the FDA for marketing pursuant to a submission received before March 29, 2023, while the second would be for a device authorized by the FDA for marketing pursuant to a submission received on or after March 29, 2023, that is no longer supported by its manufacturer. In both cases, the exception would only apply where, the regulated entity has deployed any updates or patches required or recommended by the manufacturer of the device. Similar to our proposal for exceptions to encryption at proposed 45 CFR 164.312(b)(3)(iv)(A) and (B), we recognize that some regulated entities may incur costs of replacing legacy devices because of the limitations on the proposed exception to MFA where a device was submitted to the FDA for authorization before March 29, 2023 or a device submitted for authorization on or after that date that is no longer supported by its manufacturer.^[782] However, as discussed above, such devices can pose significant risks to the confidentiality, integrity, and availability of ePHI.^[783] By limiting these exceptions to devices that have been updated and/or patched while they were supported by their manufacturer, we believe that this proposal would balance the interest in encouraging regulated entities to dispense with legacy devices with the cost of replacing such devices. Additionally, the Department believes that regulated entities should already have plans to replace legacy devices that cannot be made cybersecure because of their existing Security Rule obligations. As discussed above, we also recognize that at some point, most, if not all, devices will likely become legacy devices and that there may be legitimate reasons not to immediately replace them when the manufacturer ceases to provide support. In such cases, it will continue to be important for regulated entities to plan for how to address their ongoing Security Rule obligations.

The third proposed exception to MFA at 45 CFR 164.312(f)(2)(iii)(C)( 3 ) for devices authorized by the FDA for marketing would be available for those devices authorized for marketing by the FDA pursuant to a submission received on or after March 29, 2023, where they are supported by their manufacturer. We understand that the FDA considers security during the review of medical device marketing submissions and works with device manufacturers to ensure that appropriate cybersecurity protections are built into such devices, pursuant to FDA's authority under the Consolidated Appropriations Act, 2023.^[784] Thus, we do not believe it would be necessary or appropriate for the Security Rule to require MFA for an FDA-authorized medical device that has been authorized by FDA for marketing pursuant to a submission received on or after March 29, 2023, where the device continues to be supported by its manufacturer. However, these devices may continue to be used by a regulated entity when they are no longer supported, consistent with the proposed exception for legacy devices that were approved pursuant to a submission received on or after March 29, 2023, as described above.

Where a proposed exception would apply to the proposed MFA requirement, the Department proposes to require that a regulated entity implement alternative measures and compensating controls.^[785] Specifically, when a regulated entity seeks to comply with the Security Rule by meeting one of the proposed exceptions to the proposed MFA requirement, the Department proposes to require a regulated entity to document both the existence of the criteria demonstrating that the proposed exception would apply and the rationale for why the proposed exception would apply. ( print page 976) Additionally, the proposal would require a regulated entity to implement reasonable and appropriate compensating controls, as described at proposed paragraph (f)(2)(iv)(B).

The proposed requirements for reasonable and appropriate compensating controls are explained under proposed 45 CFR 164.312(f)(2)(iv)(B). Compensating controls are implemented in the place of MFA to protect ePHI.^[786] The Department does not propose to require that compensating controls be technical controls. Rather, a regulated entity should consider the nature of the exception, operating environment, and other appropriate circumstances to determine what controls are reasonable and appropriate and implement compensating controls effective for those circumstances. For example, if a software program does not support MFA, deploying a firewall or increasing the sensitivity of an existing firewall protecting that software may in some circumstances constitute a reasonable and appropriate compensating control.^[787] In some instances, physical safeguards may serve as reasonable and appropriate compensating controls. For example, limiting access to certain components of a relevant electronic information system to workforce members who meet certain requirements may be a reasonable and appropriate compensating control under some circumstances. In most cases, it would be reasonable and appropriate for a regulated entity to implement multiple compensating controls to ensure that the affected electronic information system is secured.

The Department proposes at proposed 45 CFR 164.312(f)(2)(iv)(B)( 1) that, to comply with an exception at paragraph (f)(2)(iii)(A) or (B) or (f)(2)(iii)(C)( 1) or ( 2), the regulated entity would be required to secure the relevant electronic information system with reasonable and appropriate compensating controls that have been reviewed, approved, and signed by the regulated entity's Security Official. Because exceptions are a departure from the designed Security Rule framework, the Department intends to ensure appropriate review by the Security Official of controls selected by the regulated entity to compensate for the absence of MFA. Merely because a regulated entity's Security Official has reviewed, approved, and signed off on compensating controls does not mean that those controls are effective. The regulated entity would also be required to give due consideration to the circumstances surrounding the exception and implement compensating controls effective for those specific circumstances.

With respect to the exception at proposed 45 CFR 164.312(f)(2)(iii)(C)( 3), the Department proposes at proposed 45 CFR 164.312(f)(2)(iv)(B)( 2) to presume that a regulated entity had implemented reasonable and appropriate compensating controls where the regulated entity has implemented the security measures prescribed and as instructed by the FDA-authorized label for the device. The proposed language recognizes that while the device's label may not specifically require deployment of an MFA solution, it may provide for a specific compensating control and the manner in which that control is to be implemented. This would include any updates, such as patches, recommended or required by the manufacturer of the device. While not required, a regulated entity would be permitted to implement additional alternative security measures and compensating controls in accordance with best practices and/or its risk analysis.

Additionally, the Department proposes at 45 CFR 164.312(f)(2)(iv)(B)( 3 ) that during any period in which compensating controls are in use, the regulated entity's Security Official would be required to review the effectiveness of the compensating controls at securing its relevant electronic information systems. While regulated entities should review implemented compensating controls on a routine basis, the Department intends for a regulated entity to periodically review the implementation and effectiveness of implemented compensating controls to ensure the continued protection of ePHI.^[788] For example, if a regulated entity's plan to migrate ePHI from hardware that does not support MFA changes such that the use of the non-MFA hardware continues for a longer period of time, the regulated entity should review implemented compensating controls to ensure ongoing effectiveness and whether new compensating controls should be implemented. We are proposing to require that the review be conducted at least once every 12 months or in response to an environmental or operational change, whichever is more frequent, and that the review be documented. Additionally, the Department proposes to require that the review be documented. If the regulated entity's Security Official review determines that certain compensating controls are no longer effective, the Department would expect the regulated entity to adopt other compensating controls that are effective to continue to meet the applicable proposed exception.

As an example of how proposed 45 CFR 164.312(f)(2)(iii) would operate in concert with proposed 45 CFR 164.312(f)(2)(iv), a regulated entity experiencing an emergency that adversely affects a relevant electronic information system and renders MFA infeasible would be required to document the following:

• The regulated entity has experienced an emergency that has adversely affected a relevant electronic information system, including the nature of the emergency and the specific circumstances that adversely affected the specific electronic information system.
• MFA has been rendered infeasible with respect to the specific relevant electronic information system adversely affected by the emergency.
• The regulated entity has put in place reasonable and appropriate compensating controls in accordance with the regulated entity's emergency access procedures and contingency plan.

As part of its documentation, a regulated entity would need to include the controls that have been deployed, a record of the fact that the compensating controls are in use, and a record indicating that the compensating controls have been reviewed and approved by the regulated entity's Security Official. Proposed 45 CFR 164.312(f)(2)(iv)(B)( 3) would require the Security Official to review and document the effectiveness of the compensating controls at least once every 12 months or in response to an environmental or operational change, whichever is more frequent. A determination regarding the effectiveness of the technical controls would be based on their ability to secure the regulated entity's ePHI and its relevant electronic information systems.

Last, we propose to add an implementation specification for maintenance at proposed 45 CFR 164.312(f)(2)(v). Under this proposal, a regulated entity would be expressly required to review and test the effectiveness of the technical controls required by this standard at least once every 12 months or in response to ( print page 977) environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

h. Section 164.312(g)—Standard: Transmission Security

Transmission security protects against the interception of ePHI in the communications networks used by regulated entities to transmit ePHI.^[789] The Department proposes to redesignate the standard for transmission security as proposed 45 CFR 164.312(g) and to modify the standard consistent with other proposals made elsewhere in this NPRM, as described below. Specifically, we propose to clarify the existing standard by requiring a regulated entity to deploy technical controls to guard against unauthorized access to ePHI in transmission over an electronic communications network. For example, adoption of health IT that is certified through the ONC Health IT Certification Program as having the technical capability to establish a trusted connection using encrypted and integrity message protection or a trusted connection for transport and deploying such capability may contribute to a regulated entity's compliance with the proposed standard for transmission security.^[790] These proposed changes are consistent with the Department's proposals to replace “implement” with “deploy” in the context of technical safeguards to differentiate between implementation of a written policy or procedure and deployment of technical controls.

Consistent with our proposals to require that regulated entities maintain their technical controls, we also propose to require a regulated entity to review and test the effectiveness of its technical controls for guarding against unauthorized access to ePHI that is being transmitted over an electronic communications network. We propose that such review and testing occur at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify such technical controls as reasonable and appropriate.

The Department also proposes to remove the implementation specification for integrity controls at 45 CFR 164.312(e)(2)(i) because these requirements are incorporated in the standard for integrity at proposed 45 CFR 164.312(e), discussed above. A regulated entity would continue to be required to review the current methods used to transmit ePHI and then deploy appropriate solutions to protect ePHI from improper alteration or destruction.^[791]

i. Section 164.312(h)(1)—Standard: Vulnerability Management

Hackers can penetrate a regulated entity's network and gain access to ePHI by exploiting publicly known vulnerabilities.^[792] Exploitable vulnerabilities can exist in many parts of the technology infrastructure of a regulated entity's relevant electronic information systems ( e.g., server, desktop, and mobile device operating systems; application, database, and web software; router, firewall, and other device firmware).^[793] A regulated entity can identify technical vulnerabilities in multiple, complementary ways, including:

• Subscribing to CISA alerts ^[794] and bulletins.^[795]

• Subscribing to alerts from the HHS Health Sector Cybersecurity Coordination Center.^[796]

• Participating in an information sharing and analysis center (ISAC) or information sharing and analysis organization (ISAO).
• Implementing a vulnerability management program that includes using a vulnerability scanner to detect vulnerabilities such as obsolete software and missing patches.
• Periodically conducting penetration tests to identify weaknesses that could be exploited by an attacker.

Additionally, CISA has compiled a database of free cybersecurity services and tools, some provided directly by CISA and others provided by private and public sector organizations.^[797] For example, public and private critical infrastructure organizations may avail themselves of CISA's Cyber Hygiene Services.^[798] These services are available at no cost to such organizations and can help regulated entities reduce their risk level, identify vulnerabilities that could otherwise go unmanaged and increase the accuracy and effectiveness of their response activities, among other benefits, putting them in a better place to make risk-informed decisions. CISA's Cyber Hygiene Services include both vulnerability scanning and web application scanning. CISA also has compiled a specific suite of tools and services for high-risk communities.^[799]

To address the potential for a bad actor to exploit publicly known vulnerabilities, and consistent with NCVHS' recommendation, the Department proposes to add a new standard for vulnerability management at 45 CFR 164.312(h)(1).^[800] The proposed standard would require a regulated entity to deploy technical controls to identify and address technical vulnerabilities in the regulated entity's relevant electronic information systems. The deployment of technical controls should be consistent with the regulated entity's patch management policies and procedures at proposed 45 CFR 164.308(a)(4). This proposed standard aligns with the Department's enhanced CPGs for Cybersecurity Testing and Third Party Vulnerability Disclosure by calling for regulated entities to employ multiple processes to discover technical vulnerabilities, including vulnerabilities in workstations and in technology assets provided by vendors and service providers.^[801] For example, a regulated entity should include a device owned by a person other than the regulated entity ( e.g., the medical device manufacturer) in its vulnerability management activities where the device is deployed on the regulated entity's network. The regulated entity should also include all workstations ( e.g., desktop computers, mobile devices) that are part of its relevant electronic information systems in its vulnerability management activities.

To implement this proposed standard, we propose four implementation specifications. Proposed 45 CFR 164.312(h)(2)(i)(A) would require a regulated entity to conduct automated scans of the regulated entity's relevant electronic information systems, including all of the components of such relevant electronic information systems ( e.g., workstations, private networks) to identify technical vulnerabilities. Vulnerability scans detect vulnerabilities such as obsolete software ( print page 978) and missing patches.^[802] Once identified, assessed, and prioritized, appropriate measures need to be implemented to mitigate these vulnerabilities ( e.g., apply patches, harden systems, retire equipment).^[803] Under the proposal, the scans would be required to be conducted in accordance with the regulated entity's risk analysis under proposed 45 CFR 164.308(a)(2) and no less frequently than once every six months.

Relatedly, proposed 45 CFR 164.312(h)(2)(i)(B) would add an implementation specification for maintenance of the technology assets that conduct the required automated vulnerability scans. Under this proposal, a regulated entity would be expressly required to review and test the effectiveness of the technology asset(s) that conducts the automated vulnerability scans that would be required by the proposed implementation specification at proposed 45 CFR 164.312(h)(2)(i)(A) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

Identification of a known vulnerability in a relevant electronic information system or a component thereof is a necessary precursor for a regulated entity to take action to mitigate the vulnerability. A 2019 study on vulnerability and patch management found that 48 percent of respondents reported that their organizations had at least one breach in the preceding two years. Of those, 60 percent said that the breaches could have occurred because an available patch for a known vulnerability had not been applied.^[804]

Accordingly, the Department also proposes a new implementation specification for monitoring at proposed 45 CFR 164.312(h)(2)(ii) to require that a regulated entity monitor authoritative sources for known vulnerabilities on an ongoing basis and take action to remediate identified vulnerabilities in accordance with the regulated entity's patch management program.^[805] The Department expects such monitoring to be conducted on an ongoing basis and is not proposing to specify a minimum time interval for reviewing sources. We are also not proposing to prescribe the specific sources of known vulnerabilities because such sources may change over time and the vulnerabilities for which regulated entities may be monitoring may vary greatly among regulated entities. We propose to require that the sources used must be authoritative. Examples of authoritative sources of known vulnerabilities would include NIST's National Vulnerability Database ^[806] and CISA's Known Exploited Vulnerabilities Catalog.^[807]

The proposed implementation specification for penetration testing at 45 CFR 164.312(h)(2)(iii) would require a regulated entity to conduct periodic testing of the regulated entity's relevant electronic information systems for vulnerabilities, commonly referred to as penetration testing. Penetration tests identify vulnerabilities in the security features of an application, system, or network by mimicking real-world attacks ^[808] and are an effective way to identify weaknesses that could be exploited by an attacker.^[809] The proposal would require such testing to be conducted by qualified person(s). We propose to describe a qualified person as a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of ePHI. We believe that within the cybersecurity industry, it is understood that a person who is qualified to conduct such penetration testing is an individual who has a combination of one or more qualifying credentials, skills, or experiences to perform “ethical hacking” or “offensive security” of information systems. The proposal would require a regulated entity to conduct such testing at least once every 12 months, or in accordance with the regulated entity's risk analysis,^[810] whichever is more frequent.

Lastly, we are proposing a new implementation specification for patch and update installation at 45 CFR 164.312(h)(2)(iv) to require a regulated entity to configure and implement technical controls to install software patches and critical updates in a timely manner in accordance with the regulated entity's patch management program.^[811] The proposed standard for patch management, an administrative safeguard discussed above, would require a regulated entity to establish and implement written policies and procedures for applying patches and updating relevant electronic information system configurations, while this proposal would require the regulated entity to implement technical controls to implement those written policies and procedures. In other words, proposed 45 CFR 164.312(h)(2)(iv) addresses the technical controls to effectuate a regulated entity's patch management plan. Applying patches for technology assets, including workstations, is an effective mechanism to mitigate known vulnerabilities and limit the risk of exploitation.^[812] Although older applications or devices may no longer be supported with patches for new vulnerabilities, regulated entities still must take appropriate action if a newly discovered vulnerability affects an older application or device. If an obsolete, unsupported system cannot be upgraded or replaced, additional safeguards should be implemented or existing safeguards enhanced to mitigate known vulnerabilities until upgrade or replacement can occur ( e.g., increase access restrictions, remove or restrict network access, disable unnecessary features or services).^[813] Deployment of such technical controls would help to ensure that a regulated entity's relevant electronic information systems are updated as quickly as possible after a vulnerability has been identified and a patch released.

The proposed standard for patch management, discussed above, would work in tandem with the proposed standard for vulnerability management to ensure that regulated entities substantially reduce the risk to ePHI from known vulnerabilities.^[814] Together, these proposals would clarify that a regulated entity is required to affirmatively seek out information about known vulnerabilities, assess the risks to the confidentiality, integrity, and availability of ePHI, and implement effective mechanisms through both policies and procedures and technical controls to reduce the risk, as well the actual occurrence, of breaches resulting from known vulnerabilities. For example, known vulnerabilities should be readily identified by a regulated entity through monitoring of ( print page 979) authoritative sources for known vulnerabilities, such as those referenced above, and remediating any identified vulnerabilities. When a vulnerability is discovered, a regulated entity, through its patch management program, should have in place a policy and procedure for applying any available patches or implementing reasonable and appropriate compensating controls if a patch is not available. Remediation may be as simple as applying a vendor-offered software patch or, in the case of software no longer supported by a vendor, designing and implementing reasonable and appropriate compensating controls to reduce the risk of the vulnerability. The policies and procedures required by the proposed standard for patch management in proposed 45 CFR 164.308(a)(4)(i) also would be implemented in part by the proposed implementation specifications associated with the proposed standard for vulnerability management. Those proposed implementation specifications would require the deployment of technical controls to ensure the patch management program is carried out, automated vulnerability scans, and penetration testing, all of which may identify when a patch or compensating control has not been put in place. The Department envisions that the full implementation of all of the proposed standards and implementation specifications would effectively reduce the risk to ePHI.

j. Section 164.312(i)(1)—Standard: Data Backup and Recovery

The Security Rule requires regulated entities to regularly create copies of ePHI to ensure that it can be restored in the event of a loss or disruption.^[815] However, OCR's enforcement experience indicates that regulated entities could benefit from a more specific standard. Consistent with the proposed standard for contingency planning at 45 CFR 164.308(a)(13)(ii)(B), the Department proposes to add a standard for a new technical safeguard for data backup and recovery. This new standard would require a regulated entity to deploy technical controls to create and maintain exact retrievable copies of ePHI. The proposed changes would remove the existing implementation specification for this activity from the physical safeguards section and place it within technical safeguards. The Department also proposes to modify the language of the existing requirement by removing the limitation that it applies before moving equipment, so that it applies broadly and comprehensively. Elevating data backup and recovery to a standard would also increase the prominence of this requirement and highlight the liability of regulated entities for creating the capacity to restore systems after a data breach.

The Department proposes four new implementation specifications for the data backup and recovery standard. The first, 45 CFR 164.312(i)(2)(i), would require a regulated entity to create copies of ePHI in a manner that ensures that such copies are no more than 48 hours older than the ePHI maintained in the regulated entity's relevant electronic information systems and in accordance with the policies and procedures required by proposed 45 CFR 164.308(a)(13)(ii)(B). The second, 45 CFR 164.312(i)(2)(ii), would require a regulated entity to deploy technical controls that, in real-time, monitor, and alert workforce members about, any failures and error conditions of the backups required by the first implementation specification. The third, 45 CFR 164.312(i)(2)(iii), would require a regulated entity to deploy technical controls that record the success, failure, and any error conditions of backups required. The fourth, 45 CFR 164.312(i)(2)(iv), would require a regulated entity to test the effectiveness of its backups and document the results at least monthly. Specifically, a regulated entity would be required to restore a representative sample of backed up ePHI (after the ePHI is backed up as required by paragraph (i)(2)(i)) and document the results of such test restorations at least monthly. Such tests should include verifying regulated entity's ability to access ePHI from a remote location.

These activities are included in NIST guidance for Security Rule compliance,^[816] which directs regulated entities to consider the following questions: Is the frequency of backups appropriate for the environment? Are backup logs reviewed and data restoration tests conducted to ensure the integrity of data backups? Is at least one copy of the data backup stored offline to protect against corruption due to ransomware or other similar attacks? The potential need for these requirements also has been indicated through the rising number of ransomware attacks and the high number of individuals affected in such incidents. The Department believes these new implementation specifications, if finalized, would provide additional instruction for regulated entities about conducting data backups and enhance the ability of regulated entities to avoid costly work stoppages and interruptions in the delivery of health care when data becomes unavailable because of a disaster, security incident, or other emergency. We believe enhanced measures for data backup would reduce the need to pay ransom to hackers to recover compromised data.

k. Section 164.312(j)—Standard: Information Systems Backup and Recovery

The Department also proposes to add a new standard for backup and recovery of relevant electronic information systems at proposed 45 CFR 164.312(j). This proposed standard would require a regulated entity to deploy technical controls to create and maintain backups of relevant electronic information systems. It would also require a regulated entity to review and test the effectiveness of such technical controls at least once every six months or in response to environmental or operational changes, whichever is more frequent, and modify them as reasonable and appropriate. The Department would not require a regulated entity to test every relevant electronic information system; rather, the requirement to test the effectiveness of the controls would permit a regulated entity to review the relevant log files and to test a representative sample of the backup of its relevant electronic information systems.

This proposed standard would reduce potential gaps in the data that needs to be backed up and recovered, to ensure that regulated entities address compliance across relevant electronic information systems. It is crucial to a regulated entity's recovery from an emergency or other occurrence, including a security incident, that adversely affects its relevant electronic information systems to create and maintain backups of such information systems that comprise the infrastructure that maintains and supports the confidentiality, integrity, and availability of ePHI. The Department would expect that the extent of this activity would be affected by the size and complexity of the relevant electronic information systems used by a regulated entity. It is also consistent with NIST guidance, which directs regulated entities to consider whether backups or images of operating systems, devices, software, and configuration files necessary to support the ( print page 980) confidentiality, integrity, and availability of ePHI.^[817]

4. Request for Comment

The Department requests comments on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether there are additional technical safeguards that the Department should require regulated entities to implement.

b. Whether there are additional implementation specifications that should be adopted for any of the proposed or existing technical safeguards.

c. Whether the Department should extend the standard for encryption and decryption and associated implementation specifications to require encryption of all relevant electronic information systems.

d. Whether there should be exceptions to any of the proposed or existing technical safeguards or related implementation specifications, in addition to those proposed for encryption and decryption and MFA. For example, are there any proposed or existing standards or implementation specifications with which small or rural regulated entities would have substantial difficulty complying? If so, please explain the type of regulated entities that would be adversely affected by the requirement, the nature of the compliance difficulty, and any alternative or compensating measures that such entities are implementing now or could implement in the event of such requirement to address the risk to ePHI posed by the specific standard or implementation specification.

e. Whether the exceptions the Department has proposed to the standard for encryption or decryption are appropriate. If not, please explain.

f. Data about the frequency and number of requests regulated entities receive pursuant to the individual right of access at 45 CFR 164.524 where an individual requests that the regulated entity transmit to the individual or a third party a copy of the individual's ePHI via unencrypted email or other unencrypted messaging technologies. Please confirm that these are requests made pursuant to the individual right of access, rather than other types of communications, such as appointment reminders or requests made pursuant to a valid authorization.

g. Whether the Department should provide any additional exceptions to standard for encryption or decryption. If so, please explain.

h. Whether there are additional criteria or parameters for encryption that regulated entities would find helpful. If yes, please explain and provide examples.

i. Whether the Department should require review of compensating controls implemented to comply with an exception to the encryption and decryption standard more frequently than once every 12 months where there are no environmental or operational changes.

j. With respect to the exception to the standard for encryption and decryption for certain requests made pursuant to the individual right of access, whether there are forms and formats the Department should include or exclude from the exception ( e.g., portable document format (PDF)). If so, please explain.

k. Resources that regulated entities have identified to help inform individuals about the risks associated with the unencrypted transmission of ePHI, and whether the Department should compile and publish a list of such resources.

l. Whether the Department should define in regulation or guidance what constitutes a prevailing cryptographic standard. If so, please explain.

m. Whether the Department should specify the deployment of a particular form or manner of encryption, such as the use of particular algorithms, protocols, or compliance standards. If so, please explain.

n. Whether the Department should specify how much time regulated entities have to implement encryption for technology assets that do not support encryption. If so, please explain.

o. Whether the Department should provide more detailed requirements for network segmentation, such as the type(s) of technologies that should be segmented and how to determine whether certain technologies should be segmented. If so, please explain.

p. Whether the exceptions the Department has proposed to the implementation specification for MFA are appropriate. If not, please explain.

q. Whether the Department should provide additional exceptions to the implementation specification for MFA. If so, please explain.

r. Whether the Department should require a regulated entity to review its compensating controls adopted to comply with the exceptions to the implementation specification for MFA more frequently than once every 12 months.

s. The costs and burdens for regulated entities to implement MFA.

t. Whether the Department should require regulated entities to deploy an endpoint detection and response (EDR), security information and event management (SIEM), or other specific solution.

u. Whether once every six months is the appropriate frequency for the automated vulnerability scans required under the implementation specification for vulnerability management. If not, please explain.

v. Whether the Department should define in regulation or guidance what constitutes an authoritative source of known vulnerabilities. If so, please explain.

w. Whether once every 12 months is the appropriate frequency for the penetration testing required under the implementation specification for vulnerability management. If not, please explain.

x. For regulated entities that have conducted penetration tests, the amount of time and costs of such tests.

G. Section 164.314—Organizational Requirements

1. Section 164.314(a)(1)—Standard: Business Associate Contracts or Other Arrangements

a. Current Provisions

The first standard in 45 CFR 164.314 contains the requirements for business associate agreements and other arrangements. The associated implementation specifications at 45 CFR 164.314(a)(2) require that a business associate agreement include provisions compelling a business associate to do all of the following: (1) comply with the requirements of the Security Rule; ^[818] (2) ensure that any subcontractors that create, receive, maintain, or transmit ePHI on behalf of the business associate agree to comply with the applicable requirements of the Security Rule by also entering into a business associate agreement; ^[819] and (3) report to the covered entity any security incident of which it becomes aware, including breaches of unsecured PHI as required by the Breach Notification Rule.^[820]

Under 45 CFR 164.314(a)(2)(ii), a covered entity that is a governmental entity is in compliance with the requirements of this section if it has in place an arrangement with a business associate that is also a governmental entity where the arrangement meets the ( print page 981) analogous requirements of the Privacy Rule at 45 CFR 164.504(e)(3).^[821]

Additionally, 45 CFR 164.314(a)(2)(iii) requires that a business associate and its subcontractor enter into a business associate agreement that meets the same requirements as those that apply to a business associate agreement between a covered entity and business associate.

As described above, a business associate agreement must include a provision that requires a business associate to report to the covered entity any known security incident. The term “security incident” includes both attempted and successful unauthorized events in an information system.^[822] The Security Rule does not prescribe the timing and frequency with which a business associate reports a security incident to the covered entity (or subcontractor to a business associate).^[823] Instead, regulated entities may determine the appropriate timing and frequency as part of their business associate agreement, consistent with the requirements of the Breach Notification Rule.^[824]

Depending on the size of the regulated entity, the number of security incidents it experiences may vary, ranging from the occasional incident experienced by a small regulated entity to more than 1,000 per hour for a large regulated entity.^[825] Given that such incidents may have little to no effect if the regulated entity's electronic information systems are able to deter it, it may not be necessary for a business associate to report the security incidents immediately to a covered entity (or a subcontractor to a business associate).

Additionally, as discussed above, regulated entities are required to establish, and implement as needed, a contingency plan ^[826] that includes the policies and procedures for responding to an emergency or other occurrence that damages systems that contain ePHI. Such emergencies or other occurrences could include a fire, vandalism, system failure, or a natural disaster.^[827] The Department believes that, in some instances, a security incident would also be an emergency or other occurrence that could require a regulated entity to activate its contingency plan.^[828] As the Department previously explained, a contingency plan is the only way to protect the confidentiality, integrity, and availability of ePHI during unexpected events that may expose ePHI because the usual security measures may be disabled, ignored, or not observed.^[829]

b. Issues To Address

In recent years, there has been an increase in the number and types of emergencies or other occurrences that cause damage to systems that contain ePHI and may require a regulated entity to activate its contingency plan. For example, we have experienced an increase in extreme weather events over the last 40 years as a result of the changing climate.^[830] Additionally, as discussed in greater detail above, there has been a significant increase in the number of breaches of unsecured PHI reported to the Department over the last five years.^[831] And increasingly, ePHI is created, received, maintained, and transmitted using cloud-based software that may be located in a remote location, which means that covered entities more frequently rely on business associates to access ePHI.^[832] Not only could the covered entity's ability to access ePHI or the relevant electronic information systems of the business associate that are affected by such an event, but the incident could also have repercussions for the covered entity's ePHI or its relevant electronic information systems. For example, a business associate's relevant electronic information systems may become infected with malicious software that spreads across devices connected to a network ( e.g., the NotPetya malware.^[833] ) If the covered entity is also connected to the same network, providing prompt notice to the covered entity of the security incident and activation of its contingency plan could enable the covered entity to prevent or mitigate damage to the covered entity's relevant electronic information systems.

When considered altogether, these developments mean that a regulated entity is more likely to experience an emergency or other occurrence that damages systems that contain ePHI than it was in either 2003 ^[834] or 2013.^[835] Unfortunately, based on the Department's experience, neither the increased risk nor the Security Rule's requirement that a business associate notify a covered entity (or that a subcontractor notify a business associate) of any security incident, including breaches of unsecured PHI, has been sufficient to encourage prompt notifications by a business associate to the covered entity (or of a subcontractor to a business associate) that its ability to ( print page 982) access ePHI or the electronic information systems that create, receive, maintain, or transmit ePHI may be affected. This lack of prompt notification delays a covered entity (or business associate) from responding and protecting its ePHI and electronic information systems accordingly.

c. Proposal

To address these risk trends and deficiencies in protections, the Department proposes to add an implementation specification at proposed 45 CFR 164.314(a)(2)(i)(D) that would require a business associate agreement to include a provision for a business associate to report to the covered entity activation of its contingency plan that would be required under 45 CFR 164.308(a)(13) without unreasonable delay, but no later than 24 hours after activation.^[836] This proposal, if finalized, would not alter the business associate's breach reporting obligations under the Breach Notification Rule.^[837] The Department believes that it is necessary to notify the covered entity in a timely manner of the contingency plan activation because of the downstream implications for such activation. Receiving such prompt notice could enable the covered entity to take the necessary steps to protect its own relevant electronic information systems, as well as to implement its own contingency plan if necessary and appropriate ( e.g., enable the covered entity to access a remote or offline backup of its ePHI if necessary to ensure that patient care is unaffected—or to reduce the effect on patient care as much as possible). For example, in 2020, a software company was the target of an attack that used software containing malware to infiltrate the electronic information systems of subsequent users of the software. This allowed cybercriminals to gain access to several government systems and thousands of private systems worldwide.^[838] Requiring a business associate to provide prompt notice to the covered entity when the business associate activates its contingency plan could enable regulated entities to maintain individuals' confidence in their commitment to protecting the confidentiality, integrity, and availability of ePHI in the event of an emergency or other occurrence that adversely affects relevant electronic information systems.^[839] Additionally, the modified standard would align with the enhanced CPG for Third Party Incident Reporting because this proposal would require a business associate to both report to a covered entity or another business associate activation of its contingency plan within 24 hours of such activation and report known or suspected security incidents.^[840]

As discussed above, the Department proposes to require a regulated entity to activate its contingency plan to respond to an emergency or other occurrence that adversely affects relevant electronic information systems.^[841] The Department believes that regulated entities activate their contingency plans infrequently because such plans are only activated when there is an emergency or other occurrence that rises to a level beyond a security incident that is thwarted or other event that does not adversely affect the confidentiality, integrity, or availability of ePHI. Thus, the need to make the proposed notification would also arise infrequently.

For example, a business associate may not be required to notify a covered entity within a certain time after a relevant electronic information system receives a basic internet command such as a ping,^[842] which happens frequently. This is because a ping in and of itself generally does not adversely affect relevant electronic information systems when it is blocked by firewall policies, and thus does not require activation of the regulated entity's contingency plan. Instead, the business associate would be required to provide such notice in instances where internet commands received by the business associate indicate potential malicious activity, such as a denial of service attack, leading to activation of its contingency plan because of an event that adversely affects the business associate's relevant electronic information systems that create, receive, maintain, or transmit ePHI or adversely affects the confidentiality, integrity, or availability of its ePHI. However, in both such instances, a business associate would still be required to provide notice to the covered entity of the ping as a security incident in accordance with the business associate agreement.^[843]

The proposal itself would only require that the business associate notify the covered entity of its activation of the contingency plan; it does not include any specific requirements with respect to the form, content, or manner of the notice. Instead, we propose to permit the covered entity and business associate to negotiate such terms and include them in their business associate agreement if they so choose.

We recognize that when such an emergency or other occurrence transpires, the focus of the affected regulated entity must be on activating its contingency plan and restoring access to ePHI and the affected relevant electronic information systems. Similarly, when the contingency plan activation is in response to a successful security incident,^[844] it may take some time to investigate and determine the cause of the security incident. Thus, this proposal would not require reporting on the cause of the contingency plan activation; it would require reporting solely on the fact that it has activated the plan. Accordingly, we believe that 24 hours would provide a business associate with sufficient time to do all of the following: determine that there is an emergency or other occurrence adversely affecting the business associate's relevant electronic information systems; determine that it needs to activate its contingency plan; identify any covered entities that need to be notified; and notify such covered entities.

This proposed requirement to provide notice without unreasonable delay, but no later than 24 hours after a ( print page 983) contingency plan is activated, would also apply when a business associate that is a governmental entity enters into an arrangement with a covered entity that is also a governmental entity where such arrangement meets the requirements of the Privacy Rule at 45 CFR 164.504(e)(3) in accordance with 45 CFR 164.314(a)(2)(ii) and when a business associate enters into a business associate agreement with a subcontractor in accordance with 45 CFR 164.314(a)(2)(iii) to notify its business associate when it has activated its contingency plan.

Additionally, the Department proposes conforming changes to the references of 45 CFR 164.308(b) throughout 45 CFR 164.314 consistent with proposals made to modify 45 CFR 164.308(b). The Department does not intend these to be substantive changes, but rather an alignment with the proposed structural modifications in 45 CFR 164.308(b).

As discussed above, the Department proposes to remove the term “required” from the implementation specification at 45 CFR 164.314(a)(2) consistent with its proposal to eliminate the distinction between addressable and required implementation specifications. We also propose a few miscellaneous non-substantive corrections to update citations in the standard at 45 CFR 164.314(a)(1)(i) and (a)(2)(iii). We do not believe that these technical amendments would add or change any regulatory, recordkeeping, or reporting requirements, nor would they change the Department's interpretation of any regulation.

2. Section 164.314(b)(1)—Standard: Requirements for Group Health Plans

a. Current Provision

The second standard in 45 CFR 164.314 requires that, except when ePHI disclosed to a plan sponsor is summary health information ^[845] or enrollment or disenrollment information,^[846] group health plan ^[847] documents must provide that the plan sponsor will reasonably and appropriately safeguard ePHI created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. Section 164.314(b)(2) requires that the plan documents of a group health plan must be amended to incorporate provisions to require the plan sponsor to:

• Implement reasonable and appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of the ePHI that it creates, receives, maintains, or transmits on behalf of the group health plan.^[848]

• Ensure that the separation between the group health plan and plan sponsor required by the Privacy Rule at 45 CFR 164.504(f)(2)(iii) ^[849] is supported by reasonable and appropriate security measures.^[850]

• Ensure that any agent to whom it provides ePHI, agrees to implement reasonable and appropriate security measures to protect the information.^[851]

• Report to the group health plan any security incident of which it becomes aware.^[852]

b. Issues To Address

Plan sponsors are not directly liable for compliance with the Security Rule because they are not regulated entities, i.e., covered entities or business associates under HIPAA. Therefore, plan sponsors' obligations to apply safeguards to ensure the confidentiality, integrity, and availability of ePHI are limited to the requirements set forth in the plan documents of its group health plan. While 45 CFR 164.314(b) generally requires that plan documents call for the implementation of Security Rule-like safeguards, the current provision does not specifically require the group health plan to require the plan sponsor or any agent to whom it provides ePHI to comply with the requirements of the Security Rule. Given the concerns we have regarding Security Rule compliance generally by regulated entities, the Department is also concerned that group health plans have not sufficiently ensured that plan documents require that plan sponsors reasonably and appropriately safeguard ePHI created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan. Additionally, the Department is concerned that group health plans may not be monitoring plan sponsors to ensure that ePHI is disclosed to a plan sponsor only if the plan sponsor voluntarily agrees to use and disclose the information only as permitted or required by the regulations.^[853]

Plan sponsors may perform certain functions that are integrally related to, or similar to, the administrative functions of group health plans, and in carrying out these functions, need access to ePHI held by the group health plan. For example, plan sponsors may perform plan administration functions on behalf of the group health plan which are specified in plan documents. The increase in cybercrime and other emergencies adversely affecting electronic information systems is not limited to regulated entities or to the health care sector; plan sponsors are experiencing similar increases in events that require the activation of contingency plans.^[854] And plan sponsors may not be reasonably and appropriately protecting the confidentiality, integrity, and availability of ePHI absent an express requirement that plan documents obligate a plan sponsor to implement the security measures in the Security Rule. Additionally, regulated entities may not have the ability to determine whether alternate security measures will accomplish the same result because they do not have access to the information systems of plan sponsors, nor would it be appropriate for them to have such access.

Additionally, the Department believes that prompt notification by a plan sponsor to the group health plan that the ability of the plan sponsor or the group health plan to access ePHI or relevant electronic information systems may be affected by a security incident is important for the same reasons discussed above in 45 CFR 164.314(a). This lack of prompt notification delays a group health plan from responding and protecting its ePHI and relevant electronic information systems accordingly.

c. Proposal

The Department proposes to modify the implementation specifications at 45 CFR 164.314(b)(2)(i) through (iii) to address concerns that group health plans may not recognize that reasonable and appropriate safeguarding of ePHI requires the implementation of security measures that are the same as, or at least equivalent to, the security measures in the Security Rule. First, we propose to rename the implementation specifications as “Safeguard implementation,” “Separation,” and ( print page 984) “Agents,” respectively. We also propose to modify all three implementation specifications to require that plan documents of the group health plan would obligate a plan sponsor or any agent to whom it provides ePHI to implement the administrative, physical, and technical safeguards of the Security Rule. The Department recognizes that plan sponsors may need access to ePHI in certain situations, such as when they perform functions that are integrally related to, or similar to, those performed by group health plans, and we believe that such information must be protected by plan sponsors in the same manner in which it is protected by group health plans and other regulated entities.^[855]

The security measures we are proposing in this NPRM are consistent with the CISA Cross-Sector CPGs,^[856] and thus should be consistent with measures plan sponsors are implementing to protect their own electronic information systems, regardless of the obligations imposed on them by plan documents. For example, the Department seeks to ensure that plan sponsors are implementing administrative safeguards, such as performing a risk analysis,^[857] to protect the confidentiality, integrity, and availability of all ePHI in its information systems; documenting required policies and procedures; and documenting implementation of such administrative safeguards, including the required policies and procedures.^[858] Thus, requiring plan sponsors to implement the same security measures that regulated entities are implementing would maintain confidence in the commitment of plan sponsors to protecting the confidentiality, integrity, and availability of ePHI in light of the increasing cybersecurity threats as discussed above.

Additionally, the Department proposes to rename the implementation specification at 45 CFR 164.314(b)(2)(iv) as “Security incident awareness.”

Similar to the discussion above, the Department proposes to add a new implementation specification for contingency plan activation at proposed 45 CFR 164.314(b)(2)(v) that would require plan documents to include a provision requiring a plan sponsor to report to the group health plan without unreasonable delay, but no later than 24 hours after activation of its contingency plan.^[859] As discussed above, the Department believes that a group health plan needs to be notified in a timely manner when a plan sponsor activates its contingency plan because of the potential implications on the ability of a group health plan to protect the confidentiality, integrity, and availability of ePHI in its relevant electronic information systems. Accordingly, we believe that 24 hours would provide a plan sponsor sufficient time to do all of the following: determine that there is an emergency or other occurrence adversely affecting the plan sponsor's relevant electronic information systems; determine that it needs to activate its contingency plan; activate its contingency plan; identify any group health plans that need to be notified; and notify such group health plans.

Similarly, as discussed above, we propose to permit the group health plan and plan sponsor to negotiate the form, content, or manner of the notice and include them in their plan documents if they so choose.

The Department believes that requiring a plan sponsor to provide prompt notice to the group health plan when the plan sponsor activates its contingency plan would enable group health plans and plan sponsors to maintain individuals' confidence in their commitment to protecting the confidentiality, integrity, and availability of ePHI.

Additionally, consistent with our proposal to revise 45 CFR 164.306, the Department proposes to remove the term “required” from the implementation specification at 45 CFR 164.314(b)(2) consistent with our overall proposal to eliminate the distinction between “required” and “addressable” implementation specifications. However, a regulated entity would still be required to comply with all standards and implementation specifications as applicable to its situation, as proposed in 45 CFR 164.306(c).

3. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. How group health plans currently ensure that plan sponsors implement reasonable and appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of ePHI.

b. Whether it is appropriate for group health plans to require plan sponsors to implement the administrative, physical, and technical safeguards of the Security Rule. If not, please explain and provide alternatives for how the Department should ensure the confidentiality, integrity, and availability of ePHI when it is disclosed to plan sponsors.

c. Whether business associates currently notify covered entities (or subcontractors notify business associates) upon activation of their contingency plans, and if so, the manner and timing of such notice.

d. Whether plan sponsors currently notify group health plans upon activation of their contingency plans, and if so, the manner and timing of such notice.

e. Whether it would be appropriate to require a business associate to notify a covered entity (or a subcontractor to notify a business associate) within 24 hours of activating its contingency plan. If not, please explain why and what would be an appropriate amount of time for such notification.

f. Whether it would be appropriate to require a plan sponsor to notify a group health plan within 24 hours of activating its contingency plan. If not, please explain why and what would be an appropriate amount of time for such notification.

g. The manner, timing, frequency, and process used by business associates to report security incidents to a covered entity (or subcontractors to business associates).

h. The manner, timing, frequency, and process used by a plan sponsor to report security incidents to a group health plan.

H. Section 164.316—Documentation Requirements

1. Current Provisions

Section 164.316(a) requires a regulated entity to implement reasonable and appropriate policies and procedures that comply with the Security Rule, taking into account the size, complexity, and capabilities of the regulated entity; ^[860] the regulated entity's technical infrastructure, hardware, and software capabilities; ^[861] the costs of security measures; ^[862] and the probability and criticality of ( print page 985) potential risks to ePHI.^[863] Such policies and procedures must be consistent with the other requirements of the Security Rule. A regulated entity is permitted to change its policies and procedures, but it must document and implement such change in accordance with the Security Rule.

The standard and implementation specifications for documentation are in 45 CFR 164.316(b). Paragraph (b)(1) requires a regulated entity to maintain the policies and procedures it implements to comply with the Security Rule in written form. Additionally, where the Security Rule requires an action, activity, or assessment to be documented, the regulated entity must maintain a written record of the action, activity, or assessment. In both cases, the written record may be electronic. Paragraph (b)(2) includes the current implementation specifications for the documentation standard. Such documentation must be retained for the later of either: (1) six years from its creation, or (2) the date it was last effective. Additionally, it must be available to those responsible for implementing the documented policies and procedures. Finally, regulated entities must periodically review their documentation and update it as needed in response to environmental or operational changes affecting the security of ePHI.

2. Issues To Address

Although this section currently addresses policies and procedures and documentation, it does not require or include standards to govern how regulated entities must implement, maintain, and document implementation of all security measures. Implementing, maintaining, and documenting implementation of all security measures is important to ensure that regulated entities make well-reasoned decisions about implementing the requirements of this rule. Just as the Department believes that it is necessary to consider expanding the definition of “security measures” to better reflect that security measures should be multi-layered, we also believe that it is necessary to consider providing a more complete instruction concerning how regulated entities must implement, maintain, and document their implementation of the required security measures.

Additionally, OCR's own experience in investigations and audits leads us to believe that many regulated entities may not be documenting their security measures or their implementation of those measures.^[864] It is critical for a regulated entity to commit to writing the security measures required by the Security Rule to ensure consistent implementation and compliance with the Security Rule. Verbal instructions may be forgotten or misconstrued, and what the regulated entity believes to be common knowledge may not be or may be relayed incorrectly between workforce members.

Additionally, based on OCR's enforcement experience, the Department believes that regulated entities may not be periodically reviewing and updating their documentation when they modify their security measures in response to environmental or operational changes affecting the security of their ePHI. Given the constant evolution of technology and the everchanging behavior of cybercriminals in response to technological evolution, the Department believes that regular review of cybersecurity-related security measures is essential for protecting the confidentiality, integrity, and availability of ePHI and relevant electronic information systems.

3. Proposals

As discussed above, the Department has proposed to revise other provisions of the Security Rule to clarify the differences between administrative and technical safeguards and between policies and procedures on the one hand and technical controls on the other hand. We have also proposed to revise other provisions of the Security Rule to clarify that a regulated entity is required to implement and maintain its administrative, physical, and technical safeguards, including its policies and procedures. These proposals clarify that such maintenance requires the review, testing, and modification of the regulated entity's security measures on a regular cadence, meaning that the regulated entity's security measures can be modified at any time. Given these proposals, the Department believes that we must also propose to revise 45 CFR 164.316 to delete the standard for policies and procedures and to modify the Security Rule's documentation requirements. Accordingly, the Department proposes to rename this section as “Documentation Requirements” and to redesignate the documentation standard as paragraph (a). We also propose to require that a regulated entity document how it considered the factors in 45 CFR 164.306(b) in the development of its written policies and procedures.

We also propose to modify the documentation standard to clarify that all required written documentation may be in electronic form. Additionally, we propose to modify the standard's two paragraphs. Specifically, the Department proposes at proposed 45 CFR 164.316(a)(1) to require that a regulated entity document the policies and procedures it has implemented to comply with the Security Rule, and as part of that documentation, explain how it considered the factors at 45 CFR 164.306(b) in the development of its policies and procedures. Relatedly, we also propose to modify 45 CFR 164.316(a)(2) to require a regulated entity to document all of the actions, activities, and assessments required by the Security Rule. The Department believes that both proposals would help to address two common problems observed in Security Rule investigations: a failure by the regulated entity to document its policies and procedures and a failure to document actions, activities, and assessments taken to comply with the Security Rule. Without such documentation, it is challenging for a regulated entity to assess and ensure its own compliance. Accordingly, we believe that our proposals to require a regulated entity to document its implementation of the Security Rule requirements would aid both the regulated entity and the Department.

Consistent with our proposal to redesignate the documentation standard as 45 CFR 164.316(a), we propose to redesignate the implementation specifications for documentation time limits, availability, and updates as proposed at 45 CFR 164.316(b)(1) through (3), respectively. Under proposed 45 CFR 164.316(b)(3), the Department proposes to require a regulated entity to update its documentation at least once every 12 months and within a reasonable and appropriate period of time after a security measure is modified.^[865] As ( print page 986) discussed above, the Department recognizes that the health care environment has changed in a way that necessitates thorough and frequent review of and updates to documentation. By proposing to specify how often documentation must be updated, the Department would clarify that we expect regulated entities to review and update their documentation at regular intervals, in addition to doing so in response any changes to a security measure. Cybersecurity and data protection is an evolving process, which makes formal, updated, and detailed documentation imperative for data protection. By reviewing and updating its documentation, including its written policies and procedures, at least annually and in response to changes to its security measures, a regulated entity should have a full understanding of its implemented security measures and be able to determine which measures should be updated to protect the confidentiality, integrity, and availability of ePHI.

As discussed above and consistent with the proposed changes to 45 CFR 164.306, the Department is proposing to remove the term “required” from 45 CFR 164.316(b)(1) through (3).

4. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following consideration in particular:

a. Whether it would be appropriate to require regulated entities to review and update documentation for security measures at least once every 12 months. If not, please explain.

b. Whether it is clear that 45 CFR 164.316 provides regulated entities with directions on when and how they are to document all security measures across all safeguard requirements. If not, please explain.

c. Whether it is feasible for regulated entities to document all of the actions, activities, and assessments required by the Security Rule as proposed at 45 CFR 164.316(a)(2). If not, please explain.

I. Section 164.318—Transition Provisions

1. Current Provisions and Issues To Address

Section 164.318 established the compliance dates for the initial implementation of the security standards for health plans, health care clearinghouses, and health care providers in 2005 and 2006.^[866] Covered entities have been required to comply with the security standards for almost 20 years, and the initial implementation of the security standards is no longer applicable. Because of this, the Department believes that these provisions are no longer necessary.

2. Proposal

The Department proposes to remove the information in 45 CFR 164.318 and replace the language with provisions for transitioning to the revised Security Rule, should the proposals included in this NPRM be adopted.

The Department understands that regulated entities may be concerned with the anticipated administrative burden and cost of revising their business associate agreements or other written arrangements to comply with a revised Security Rule. For example, a regulated entity would need to update its business associate agreements to add a provision specifying that the business associate will report to the covered entity ^[867] that it activated its contingency plan no later than 24 hours after activation of such plan.^[868] A regulated entity may have existing contracts that are not set to terminate or expire until after the compliance date for a final rule modifying the Security Rule, and we understand that a six-month compliance period may not provide enough time to reopen and renegotiate all contracts, in addition to ensuring that all regulated entities are compliant with the revised Security Rule. Accordingly, the Department proposes to relieve some of the burden on regulated entities by adding a specified period of transition for certain existing contracts.

The Department's authority to provide a transition period is expressed in 45 CFR 160.104(c), which allows the Secretary to establish the compliance date for any modified standard or implementation specification, considering the extent of the modification and the time needed to comply with the modification.^[869]

Given these considerations, to allow regulated entities enough time to update thousands of existing business associate agreements or other written arrangements, the Department proposes to provide additional time to update the contracts required by 45 CFR 164.314(a)(1).

Specifically, the Department proposes to add new transition provisions under 45 CFR 164.318 to allow regulated entities to continue to operate under certain existing business associate agreements or other written arrangements until the earlier of: (1) the date such contract or other arrangement either is renewed on or after the compliance date of the final rule; or (2) a year after the effective date of the final rule. The additional transition period would be available to regulated entities if both of the following conditions are met: (1) prior to the publication date of the final rule, the covered entity or business associate had an existing business associate agreement or other written arrangement with a business associate or subcontractor, respectively, that complied with the Security Rule prior to the effective date of a final rule revising the Security Rule; and (2) such contract or arrangement would not be renewed or modified between the effective date and the compliance date of the final rule.

Under the proposed transition provisions, a business associate would be permitted to create, receive, maintain, or transmit ePHI pursuant to an existing business associate agreement or other written arrangement with another regulated entity that does not require the regulated entity to obtain satisfactory assurances that meet the requirements of the revised Security Rule for up to one year after the revised Security Rule becomes effective, assuming that a final Security Rule is published; and that the agreement is compliant with the Security Rule at the time the final rule is published and that it is not renewed or modified between the effective and compliance dates.^[870] The transition provisions would also allow for the business associate to create, receive, maintain, or transmit ePHI on behalf of another regulated entity where the existing business associate agreement does not require that the regulated entity verify that the ( print page 987) business associate has deployed technical safeguards in accordance with the Security Rule under the same circumstances as those described above.^[871]

During the transition period, the Department proposes to allow a business associate to create, receive, maintain, or transmit ePHI pursuant to a business associate agreement or other written arrangement with another regulated entity without including in the agreement that the business associate will: (1) comply with the revised Security Rule; ^[872] (2) ensure that any subcontractors that create, receive, maintain, or transmit ePHI on behalf of the business associate agree to comply with the revised Security Rule by entering into a business associate agreement or other arrangement that meets the requirements of the revised rule; ^[873] and (3) report to the covered entity ^[874] activation of its contingency plan.^[875]

Additionally, the Department intends that, in cases where a contract renews automatically without any change in terms or other action by the parties (also known as “evergreen contracts”), such contracts would be eligible for the extension if they automatically renew between the effective and compliance dates. Thus, regulated entities with an evergreen contract will be deemed to be in compliance with the Security Rule's requirements for business associate agreements or other written arrangements and such deemed compliance would not terminate when these contracts automatically renew. These transition provisions would apply to written contracts or other written arrangements as specified above.

These transition provisions would apply only to the requirement to amend contracts or other arrangements with business associates, and they would not affect any other compliance obligations under the Security Rule. For example, beginning on the compliance date of the final rule, assuming a final rule is published and that it is finalized as proposed, a business associate would be required to implement and document its implementation of the administrative, physical, and technical safeguards required by a revised Security Rule, except with respect to 45 CFR 164.308(b) and 164.314(a), even if the business associate's contract with the covered entity ^[876] has not yet been amended.

Given the possibility of a similar burden on group health plans and plan sponsors to update plan documents by the compliance date, the Department is considering, but not proposing, a similar transition provision for plan documents. We are not proposing such provisions at this time because, unlike business associates, plan sponsors do not have independent obligations under the Security Rule. Instead, the obligations of plan sponsors are based entirely on the content of the plan documents. Accordingly, if the plan documents are not updated, plan sponsors are not obligated to comply with the requirements of the Security Rule because they are not regulated entities.

In particular, the Department is considering, but not proposing at this time, adding a new paragraph (d) introductory text under 45 CFR 164.318, with the heading “Standard: Effect of prior plan documents for group health plans,” stating that notwithstanding any other provisions of the subpart, a group health plan may allow a plan sponsor to create, receive, maintain, or transmit electronic protected health information pursuant to a written plan document with such group health plan that does not comply with § 164.314(b), only in accordance with paragraph (d)(1). The Department is also considering adding a new paragraph (d)(1) under 45 CFR 164.318, with the heading “Implementation specification: Plan documents for group health plans,” stating that the requirements of paragraph (b) apply to the plan document between a group health plan and a plan sponsor in the same manner as such requirements apply to written contracts or other arrangements between a covered entity and a business associate.

Similarly, the Department is considering, but not proposing at this time, adding a new paragraph (d)(2) under 45 CFR 164.318, with the heading “Group health plan responsibilities,” stating that nothing in the section shall alter the requirements of a group health plan or plan sponsor to comply with the applicable provisions of the part other than § 164.314(b).

3. Request for Comment

The Department requests comment on the foregoing proposals, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether the Department's proposal to provide regulated entities with additional time to revise business associate agreements or other written contracts is appropriate. If not, please explain.

b. Whether the Department should also provide group health plans and plan sponsors additional time to revise plan documents by adding a transition provision to grandfather certain existing plan documents for a specified period of time.

c. Whether the Department should consider additional constraints or specificity for a new paragraph (d) to allow group health plans more time to comply with the Security Rule requirements for plan documents.

J. Section 164.320—Severability

The Department intends that, if any provisions of this subpart, including the provisions of this NPRM, if finalized, were held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of this subpart, and from other rules and regulations currently in effect, and not affect the remainder of this subpart. It is also our intent that, unless such provision shall be held to be utterly invalid or unenforceable, it shall be construed to give the provision maximum effect to the provision permitted by law, including in the application of the provision to other persons not similarly situated or to other dissimilar circumstances from those where the provision may be held to be invalid or unenforceable.

The provisions of this subpart, including the proposals of this NPRM, are intended to operate independently of each other, even if multiple provisions serve the same or similar general purpose(s) or policy goal(s). Where a provision is necessarily dependent on another, the context generally makes that clear, such as by cross-reference to a particular standard, requirement, or implementation specification. Where a provision that is dependent on one that is stayed or held invalid or unenforceable, as described in the preceding paragraph, is included in paragraph or section within 45 CFR part 160 or 164, we intend that other provisions of such paragraph(s) or section(s) that operate independently of said provision would remain in effect.

The Department intends the individual standards in 45 CFR 164.308, 164.310, 164.312, 164.314, and 164.316 to apply separately to govern how a regulated entity must protect the security of all ePHI it creates, receives, ( print page 988) maintains, or transmits. Accordingly, if finalized, this provision would provide that if any one or several standards in 45 CFR 164.308, 164.310, 164.312, 164.314, and 164.316 are deemed invalid by a court, or non-applicable to a particular person or circumstance, all remaining standards shall be unaffected and shall remain in force, and any remaining component of the adjudicated provision, not invalid or found to be unenforceable or inapplicable, shall be considered by the Department to be still in effect.

For example, the standard for risk analysis proposed in 45 CFR 164.308(a)(2) would protect ePHI from risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI, while the modified standard for workforce security proposed in 45 CFR 164.308(a)(9) would protect ePHI from inappropriate access by a regulated entity's workforce. An invalidated standard for workforce security would not render the entire rule unworkable because a regulated entity could still meet the requirement to conduct the risk analysis without regard to whether the entity meets the requirements included in the standard for workforce security. Similarly, were a court to invalidate the Department's proposal in 45 CFR 164.310(a)(1) requiring that implemented policies and procedures to limit physical access to relevant electronic information systems and the facility or facilities in which they are housed be in writing, a regulated entity could still meet a requirement to implement the policies and procedures. Similar considerations apply to the proposal for written policies and procedures in proposed 45 CFR 164.316(a), and to proposals that are deemed inapplicable to certain persons or circumstances.

Further, the Department believes it is necessary to clarify how regulated entities would continue to apply implementation specifications in the event a court invalidates or deems inapplicable a governing standard over a specific implementation specification, or if a court invalidates or deems inapplicable one or several implementation specifications without taking adverse action on the governing standard. The Department does not interpret that this severability proposal, if finalized, would apply to implementation specifications in the same manner as it would apply to standards. Because the implementation specifications are regulatory instructions on how a regulated entity is to comply with a particular standard, if any standard is stricken, all implementation specifications underneath are similarly stricken. Conversely, the Department does not intend for the overarching standard to be affected by a court's decision to invalidate or make a determination of non-applicability to particular person or circumstance all implementation specifications under a particular standard. The Security Rule would still retain its flexible and scalable approach, and, therefore, a regulated entity could use any reasonable and appropriate security measure to implement the standard consistent with 45 CFR 164.306(b), even if all implementation specifications under the standard are stricken.

If a court invalidates or deems inapplicable less than all implementation specifications under a specific standard ( i.e., only one or several), the ability of a regulated entity to execute the remaining implementation specification(s) depends on whether the remaining implementation specifications are dependent on one another or operate together to impose requirements on regulated entities. For example, several proposed implementation specifications under the standard for facility access controls at 45 CFR 164.310(a)(1) would require a regulated entity to both establish and implement written procedures pertaining to specific requirements such as contingency operations, facility security planning and access control and validation, and then subsequently review the written policies and procedures every 12 months. Should a court invalidate or deem inapplicable the implementation specification to establish and implement written policies procedures, the secondary specification requiring review of said procedures would also become invalid.

The Department believes that each definition is independent of all other definitions.

This list of examples is not intended to be exhaustive. The absence from this list of any particular provision should not be construed to mean that the Department considers that provision to be not severable from other parts of the rule.

To ensure that our intent for severability of provisions is clear in the CFR, the Department proposes to add a section on severability at 45 CFR 164.320. Proposed 45 CFR 164.320 would state our intent that if any provision of this subpart is held to be invalid or unenforceable, it shall be construed to give maximum effect to the provision permitted by law unless the holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this subpart and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.

The Department requests comment on the foregoing proposal, including any benefits, drawbacks, or unintended consequences.

K. New and Emerging Technologies Request for Information

Technology is constantly evolving, able to perform increasingly complex tasks, including those with the potential to improve health care and communication between individuals and care providers. These new and evolved technologies will continue to transform health care in a variety of ways, including providing regulated entities with new tools for faster and more accurate diagnoses, effective treatments, and more efficient administration.

As a regulated entity considers the application of new technologies or the use of existing tools in innovative ways, it also must consider whether these technologies create, receive, maintain, or transmit ePHI, and, if so, how to secure them. The Security Rule was designed to be technology-neutral for this very reason and continues to provide the foundation for ensuring the confidentiality, integrity, and availability of all ePHI as technology changes.^[877] As a result, while the technology may be new or developing, securing ePHI involved with the technology can be successfully executed through compliance with the Security Rule.

Before implementing new and emerging technologies, a regulated entity must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI.^[878] It must then implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.^[879] Such administrative, physical, and technical safeguards apply to all instances of ePHI maintained or transmitted by the regulated entity, regardless of the technology used. Below, we discuss some examples of new technologies, such as quantum computing, AI, and virtual and augmented reality (VR and AR), and ( print page 989) how the Security Rule would apply in each case.

1. Quantum Computing

Several Federal agencies have considered the potential benefits and drawbacks of quantum information science,^[880] that is, the study of “the impacts of quantum physics properties on information science. Those properties can increase computational power and speed significantly over classical computers, provide precision measurements; enhance sensing capabilities; and increase the accuracy of position, navigation, and timing services.” ^[881] According to NIST, “In recent years, there has been a substantial amount of research on quantum computers—machines that exploit quantum mechanical phenomena to solve mathematical problems that are difficult or intractable for conventional computers.” ^[882]

However, the increase in computational capability threatens the security of asymmetric cryptography,^[883] which is critical to encryption solutions, a key protection for ePHI and other sensitive information today. Scientists warn that when such quantum computers are built, they will have the ability to break many of the systems for asymmetric cryptography that are in use today.^[884] Thus, experts anticipate that quantum computing will adversely affect the confidentiality and integrity of digital communications.^[885] “The goal of post-quantum cryptography (also called quantum-resistant cryptography) is to develop cryptographic systems that are secure against both quantum and classical computers, and can interoperate with existing communications protocols and networks.” ^[886] A recent National Security Memorandum affirmed that “alongside its potential benefits, quantum computing also poses significant risks to the economic and national security of the United States. . . . [including the potential to break] much of the public-key cryptography used on digital systems across the United States and around the world.” ^[887] Accordingly, the White House has directed Federal agencies to take specific steps to “mitigate the threat of [cryptanalytically relevant quantum computers] through a timely and equitable transition of the Nation's cryptographic systems to interoperable quantum-resistant cryptography.” ^[888]

NCVHS examined these security issues and provided recommendations to the Department for applying the safeguards of the HIPAA Rules to potential quantum computing threats. Specifically, NCVHS declared that incorporation of recent Administration guidance for Federal agencies “on vulnerable cryptographic systems is necessary to strengthen the Technical Safeguards within the Security Rule.” ^[889] This joint guidance, developed by NIST, CISA, and NSA, encourages “the early planning for migration to post-quantum cryptographic standards by developing a Quantum-Readiness Road map.” ^[890] It also recommends that organizations prepare a cryptographic inventory, discuss post-quantum roadmaps with technology vendors, consider their supply chain's readiness for quantum computing, and consider the responsibilities of their technology vendors with respect to preparing for quantum readiness.^[891]

The Department encourages regulated entities to incorporate these activities as part of their ongoing risk management programs. For example, the steps presented in the joint guidance—surveying the environment for potential risks and vulnerabilities that endanger ePHI, identifying workforce members with responsibility for addressing them, inventorying quantum-vulnerable systems, including that inventory in its risk analysis and risk management, and working with technology vendors to ensure their readiness—are all activities that already are required by the administrative safeguards of the Security Rule.

We believe these obligations would be clarified by the proposals in this NPRM. For example, the Department proposes to require that a regulated entity not only conduct an accurate assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI it creates, receives, maintains, or transmits, but would add an express requirement that the assessment be comprehensive and in writing. We also propose to specify that the required assessment include, among other things, identification of all reasonably anticipated threats and potential vulnerabilities and predisposing conditions, making a reasonable determination and documentation of the likelihood that each identified threat will exploit the identified vulnerabilities, and performing a written assessment of the risk level for each identified threat and vulnerability. Under the NPRM, a regulated entity would be expected to, as part of the risk analysis, consider whether quantum computing poses a reasonably anticipated threat to the confidentiality, integrity, or availability of its ePHI and whether there is a vulnerability or predisposing condition that corresponds to that threat, and to document those considerations; make a reasonable determination and document the likelihood that the threat will exploit the identified vulnerabilities; and assign a risk level to the identified threat and vulnerability.

2. Artificial Intelligence (AI)

Section 238(g) of the John S. McCain National Defense Authorization Act for Fiscal Year 2019 defined AI to include the following: ^[892]

• Any artificial system that performs tasks under varying and unpredictable circumstances without significant human oversight, or that can learn from experience and improve performance when exposed to data sets.
• An artificial system developed in computer software, physical hardware, or other context that solves tasks requiring human-like perception, ( print page 990) cognition, planning, learning, communication, or physical action.
• An artificial system designed to think or act like a human, including cognitive architectures and neural networks.
• A set of techniques, including machine learning, that is designed to approximate a cognitive task.
• An artificial system designed to act rationally, including an intelligent software agent or embodied robot that achieves goals using perception, planning, reasoning, learning, communicating, decision making, and acting.

AI requires enormous amounts of data to develop, but it also has enormous potential benefits. The Department has previously stated that these “technologies have the potential to drive innovation, increase market competition, and vastly improve care for patients and populations.” ^[893] According to experts, “[. . .]AI is unlocking new possibilities by advancing medicine in entirely unimaginable ways and solving some of the grand global healthcare challenges.” ^[894] And FDA agrees: “AI technologies are transforming health care by producing diagnostic, therapeutic, and prognostic medical recommendations, or decisions, in some cases independently, informed by the vast amount of data generated during the delivery of health care.” ^[895] In medical devices, areas for AI application include:

• Image acquisition and processing
• Early disease detection
• More accurate diagnosis, prognosis, and risk assessment
• Identification of new patterns in human physiology and disease progression
• Development of personalized diagnostics
• Therapeutic treatment response monitoring ^[896]

For example, clinicians are using AI to distill large volumes of EHR information about a complex patient into a summarized note that they can use to consider diagnoses and treatment. AI also has been used for aid in the detection of diabetic retinopathy, screening for breast and lung cancer, and classification of skin conditions.^[897] Others are using ambient AI scribes, a technology that uses microphones to transcribe encounters with patients in real-time.^[898] This tool creates clinical documentation that clinicians can later edit, which can lead to improved interactions with patients and reduced time on documentation.^[899] Newer AI tools may search medical records for relevant information regarding common conditions and other risk factors ^[900] or offer relevant questions for clinicians to pose to make an accurate diagnosis.^[901]

Unfortunately, AI can also be used to harm individuals, both intentionally and unintentionally. Bad actors are using generative AI to threaten the privacy and security of ePHI more effectively through phishing and other social engineering. As explained by NCVHS, “AI tools can create mass scale [cyberattacks] that are highly effective and major threats to ePHI.” ^[902] Experts anticipate that AI “will ultimately pioneer the malicious use of [. . .] ‘Offensive AI’—highly sophisticated and malicious attack code—[that] will be able to mutate itself as it learns about its environment, and to expertly compromise systems with minimal chance of detection.” ^[903] Such experts are concerned about the level of destruction that will lie in its wake and compare it to an arms race that can only escalate.^[904] Indeed, it seems likely that regulated entities will need to invest in AI to defend against malicious use of AI in the future.^[905]

After assessing current and potential AI threats, NCVHS recommended that the Department clarify how the HIPAA Rules apply to AI.^[906] We agree with their assessment and recommendation. Specifically, ePHI, including ePHI in AI training data, prediction models, and algorithm data that is maintained by a regulated entity for covered functions is protected by the HIPAA Rules and all applicable standards and specifications.^[907] For example, generative AI tools have produced in their output the names and personal information of persons included in the tools' sources of training data.^[908] Similar uses of generative AI by regulated entities, including the training of AI models on patient data, could result in impermissible uses and disclosures, including exposure to bad actors that can exploit the information.^[909] As part of its risk analysis and risk management activities, a regulated entity must consider the risk associated with different uses and data.^[910] Accordingly, we expect that a regulated entity interested in using AI would include the use of such tools in its risk analyses and associated risk management activities. The regulated entity's risk analysis must include consideration of, among other things, the type and amount of ePHI accessed by the AI tool, to whom the data is disclosed, and to whom the output is provided. The NIST AI Risk Management Framework is a helpful resource for regulated entities to better ( print page 991) understand, measure, and manage risks, effects, and harms of AI.^[911]

The Security Rule requires a regulated entity to conduct repeated risk analyses that consider any changes to its environment or operations, such as updates or changes in technology or clinical administration, and to apply all reasonable updated protections to safeguard ePHI.^[912] Accordingly, as technology such as AI evolves, the Department would expect a regulated entity to perform a risk analysis to consider the effects of such changes on the confidentiality, integrity, and availability of ePHI. As NCVHS observed, “[I]t is important to conduct risk analyses on AI throughout the life cycle of the system.” ^[913] We believe the proposals in this NPRM would clarify our expectations for when and how regulated entities need to consider, prepare for, and address such changes. For example, the Department proposes to expressly require that a regulated entity develop a written inventory of its technology assets. Under this proposal, the Department would expect that AI software used to create, receive, maintain, or transmit ePHI or that interacts with ePHI, including where ePHI is used to train the AI software, would be listed as part of its technology asset inventory, which feeds into the regulated entity's risk analysis. Making AI safe and secure with respect to ePHI requires efforts in a variety of areas—biotechnology, cybersecurity, critical infrastructure—to address risks.^[914] The Federal Government seeks to ensure that the collection, use, and retention of ePHI is lawful and secure, and that it mitigates privacy and confidentiality risks. Across the administration, Federal agencies are considering potential uses for AI, as well as their benefits and risks, consistent with E.O. 11410 and its principles to advance and govern the development and use of AI.^[915] These principles include making AI safe and secure and protecting privacy and civil liberties. For example, the Department finalized regulations earlier this year that improve transparency by health IT developers of certified health IT, including those that are business associates, that supply a particular type of AI—predictive decision support interventions (DSIs).^[916] Specifically, the regulations require such health IT developers to provide greater transparency about the design, development, training, evaluation, and use of such predictive DSIs.^[917] This approach promotes responsible AI and makes it possible for covered entities to access a consistent, baseline set of information about the algorithms they use to support their decision making and to assess such algorithms for fairness, appropriateness, validity, effectiveness, and safety.^[918]

Additionally, the Department proposes to require that regulated entities monitor authoritative sources for known vulnerabilities and to remediate such vulnerabilities in accordance with their patch management program. We also propose to require that patches, updates, and upgrades that address critical and high risks be applied promptly. Together, these proposals would support the rapid response to vulnerabilities that will be necessary as AI becomes more prevalent. Thus, the Department believes that the adoption of the cybersecurity best practices proposed in this NPRM is an important first step to ensuring that AI tools are deployed by regulated entities in a manner that protects the confidentiality, integrity, and availability of ePHI.

3. Virtual and Augmented Reality (VR and AR)

Research on VR and AR technologies is widespread and has produced numerous applications in the health care fields. Such technologies are being used in medical education and patient care, including AR-assisted surgeries, VR-based pain management therapies, and immersive patient education tools.^[919] Additionally, innovators are working on ways to incorporate AI with VR and AR for improved diagnostics and treatment planning.^[920]

However, as with quantum computing and AI, VR and AR technologies raise new privacy and security concerns. VR and AR involve the use of diverse technologies and the collection of a wide array of sensitive information, including comprehensive biometric data.^[921] According to experts, “[. . .] VR and AR present distinct security challenges, encompassing typical vulnerabilities associated with electronic devices, as well as potential risks of physical harm and leakage of highly sensitive data.” ^[922] VR, like any connected computing device, “is susceptible to standard cybersecurity concerns and various types of cyberthreats, necessitating proactive anticipation.” ^[923]

These cybersecurity risks, such as hacking, social engineering, malicious software, and ransomware, can be mitigated through holistic risk analysis and risk management, consistent with the Security Rule administrative standards in 45 CFR 164.308. In addition, patch management,^[924] access control,^[925] authentication,^[926] and appropriate business associate agreements ^[927] are examples of some of the required safeguards that would apply to VR and AR systems.

We believe the proposals in this NPRM to clarify these safeguards would substantially improve the ability of regulated entities to address these cybersecurity risks. For example, the Department proposes to require that a regulated entity obtains from a business associate written verification that the business associate has deployed the technical safeguards required by the Security Rule, including a written analysis of the business associate's information systems from a person with ( print page 992) appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of ePHI verifying compliance with the requirements of 45 CFR 164.312 and a written certification that the analysis has been performed and is accurate. Under this proposal, a regulated entity would be required to obtain such verification from a business associate-developer of VR/AR software, ensuring that ePHI that is created, received, maintained, or transmitted using the VR/AR software is protected to the same extent as ePHI that is created, received, maintained, or transmitted using other technology assets that are components of the regulated entity's relevant electronic information systems.

Many regulated entities are piloting innovative technologies. Such entities generally have separate departments that research, develop, test, and deploy such technologies.^[928] Regulated entities might consider integrating workforce members with expertise in security and privacy into their technology development groups to ensure that privacy and security, including the Security Rule-required safeguards, are embedded into the design of new and emerging technologies.^[929] Doing so can help improve security “while boosting quality, efficiency, and productivity.” ^[930]

4. Request for Comment

The Department requests comment on the foregoing discussion of how the Security Rule protects ePHI used in new and developing technologies, including any benefits, drawbacks, or unintended consequences. We also request comment on the following considerations in particular:

a. Whether the Department'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.

b. 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.

c. Whether there are additional policy or technical tools that the Department may use to address the security of ePHI in new technologies.

V. Regulatory Impact Analysis

A. Executive Order 12866 and Related Executive Orders on Regulatory Review

The Department of Health and Human Services (HHS or “Department”) has examined the effects of this proposed rule under Executive Order (E.O.) 12866, Regulatory Planning and Review,^[931] E.O. 13563, Improving Regulation and Regulatory Review,^[932] E.O. 14094, Modernizing Regulatory Review,^[933] the Regulatory Flexibility Act ^[934] (RFA), the Unfunded Mandates Reform Act of 1995 ^[935] (UMRA), and E.O. 13132 on Federalism.^[936] E.O.s 12866 and 13563 direct the Department to assess all costs and benefits of available regulatory alternatives and, when regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety, and other advantages; distributive effects; and equity). The proposed rule meets the criteria as significant under section 3(f)(1) of E.O. 12866, as amended by E.O. 14094.

The RFA requires us to analyze regulatory options that would minimize any significant effect of a rule on small entities. As discussed in greater detail below, this analysis concludes, and the Secretary certifies, that the notice of proposed rulemaking (NPRM), if adopted, would not result in a significant economic effect on a substantial number of small entities.

The UMRA (section 202(a)) generally requires us to prepare a written statement, which includes an assessment of anticipated costs and benefits, before proposing “any rule that includes any Federal mandate that may result in the expenditure by State, local, and Tribal governments, in the aggregate, or by the private sector, of $100,000,000 or more (adjusted annually for inflation) in any 1 year.” ^[937] The current threshold after adjustment for inflation is $183 million, using the most current (2024) Implicit Price Deflator for the Gross Domestic Product. UMRA does not address the total cost of a rule. Rather, it addresses certain categories of cost, mainly Federal mandate costs resulting from imposing enforceable duties on State, local, or Tribal governments or the private sector; or increasing the stringency of conditions in, or decreasing the funding of, State, local, or Tribal governments under entitlement programs.

This proposed rule, if adopted, would impose mandates that would result in the expenditure by State, local, and Tribal governments, in the aggregate, or by the private sector, of more than $183 million in any one year. The impact analysis in this proposed rule addresses such effects both qualitatively and quantitatively. Each covered entity and business associate (collectively, “regulated entity”), including government entities that meet the definition of covered entity ( e.g., State Medicaid agencies), would be required to: conduct a Security Rule compliance audit; report to covered entities or business associates, as applicable, upon activation of their contingency plan; deploy multi-factor authentication (MFA) in and penetration testing of relevant electronic information systems; complete network segmentation; disable unused ports and remove extraneous software; update cybersecurity policies and procedures; revise business associate agreements; and update workforce training. Business associates would be required to conduct an analysis and provide verification of their compliance with technical safeguards and covered entities would be required to obtain verification from business associates (and business associates from their subcontractors). Additionally, group health plans would need to revise plan documents to require plan sponsors to comply with administrative, physical, and technical safeguards according to the Security Rule standards. Finally, through contractual language, health plan sponsors would need to enhance safeguards for electronic protected health information (ePHI) according to the Security Rule standards. Costs for all regulated entities to change their policies and procedures alone would increase costs above the UMRA threshold in one year, and costs of health plan sponsors would increase total costs further. Although Medicaid makes Federal matching funds available for States for certain administrative costs, these are limited to costs specific to operating the Medicaid program. There are no Federal funds directed at Health Insurance Portability and Accountability Act of 1996 (HIPAA) compliance activities.

The Department believes that pursuant to Subtitle E of the Small Business Regulatory Enforcement ( print page 993) Fairness Act of 1996,^[938] the Office of Management and Budget's (OMB's) Office of Information and Regulatory Affairs would be likely to determine that when finalized, this rule meets the criteria set forth in 5 U.S.C. 804(2) because it is projected to have an annualized effect on the economy of more than $100,000,000.

The Justification for this Rulemaking and Summary of Proposed Rule Provisions section at the beginning of this preamble contain a summary of this rule and describe the reasons it is needed. We present a detailed analysis below.

1. Summary of Costs and Benefits

The Department identified ten categories of quantifiable costs arising from these proposals that would apply to all regulated entities: (1) conducting a Security Rule compliance audit; (2) obtaining written verification from their business associates or subcontractors that the business associates or subcontractors, respectively, have conducted the required verification of compliance with technical safeguards; (3) notifying other regulated entities when workforce members' access to ePHI is terminated; (4) completing network segmentation; (5) disabling ports and removing extraneous software; (6) deploying MFA; (7) deploying penetration testing; (8) updating policies and procedures; (9) updating workforce training programs; and (10) revising business associate agreements. Additionally, group health plans would be required to update plan documents to require health plan sponsors' compliance with the administrative, physical, and technical safeguards according to the Security Rule and notification of group health plans when health plan sponsors activate their contingency plan. Business associates would have additional obligations to verify compliance with technical safeguards and provide it in writing to covered entities (and subcontractors to business associates) and to notify covered entities upon activation of their contingency plans. Finally, although plan sponsors are not directly subject to the HIPAA Rules, by virtue of the plan document requirements, the Department estimates that certain group health plan sponsors ( e.g., employers that provide group health benefits) would likely incur some quantifiable costs to improve safeguards for their electronic information systems that affect the confidentiality, integrity, or availability of ePHI and to notify group health plans upon activation of plan sponsors' contingency plan.

The Department estimates that the first-year costs attributable to this proposed rule total approximately $9 billion. These costs are associated with regulated entities and health plan sponsors engaging in the regulatory actions described above. For years two through five, estimated annual costs of approximately $6 billion are attributable to costs of recurring compliance activities. Table 1 reports the present value and annualized estimates of the costs of this proposed rule covering a 5-year time horizon. Using a 2 percent discount rate, the Department estimates that this proposed rule would result in annualized costs of $6.8 billion for regulated entities and health plan sponsors combined.

Table 1—Accounting Table, Costs of the Proposed Rule, $ Billions  ^a

Costs	Primary estimate	Year dollars	Discount rate	Period covered
Present Value	$34	2023	Undiscounted	2026-2030
Present Value	32	2023	2%	2026-2030
Annualized	7	2023	2%	2026-2030
a  Figures are rounded.

As a result of the proposed changes in this NPRM, the enhanced security posture of regulated entities would likely reduce the number of breaches of ePHI and mitigate the effects of breaches that nonetheless occur. The Department has partially quantified these effects and presents them in a break-even analysis. The break-even analysis estimates that if the proposed changes in the NPRM reduce the number of individuals affected by breaches by 7 to 16 percent, the revised Security Rule would pay for itself. Alternatively, the same cost savings may be achieved by lowering the cost per affected individual's ePHI by 7 percent ($35) to 16 percent ($82), respectively.

The changes to the Security Rule would likely result in important benefits and some costs that the Department is unable to fully quantify at this time. As explained further below, unquantified benefits include reductions in reputational, financial, and legal harm from breaches of individuals' ePHI, reductions in disruptions to health care delivery, increased confidence among parties to health care business transactions, and improved quality of health care.

Benefits ^a

Would benefit individuals by shielding them from unwanted disclosure of their ePHI and resulting reputational, financial, and legal harms from ePHI misuse.

Would reduce reputational damage to regulated entities resulting from breaches.

Would increase confidence among parties to health care business transactions that ePHI is protected to a higher degree than previously.

Would reduce risk of breaches of ePHI by health plan sponsors.

Would help to prevent health care cost increases to recoup financial losses from responding to breaches.

Would help guard against potential data loss.

Would help minimize potential disruption of service for individuals served by any of the affected entities.

^a  Some of the items in this list represent differing perspectives on the same effect. In such cases, if more thorough quantification became feasible, we would take steps to avoid double-counting when summing the quantitative estimates.

( print page 994)

The Department also recognizes that there may be some costs that are not readily quantifiable, notably, actions that regulated entities may take to comply with existing requirements more fully as a result of proposed clarifications. For example, this would include completing a technology asset inventory, which is a baseline expectation for the existing requirement of conducting a risk assessment; documenting completion of existing requirements; adding more specificity to the required contingency plan, such as designating staff roles with specific responsibilities when a contingency occurs; testing safeguards as part of reviewing and updating policies and procedures and technical controls; and deploying encryption for ePHI in a more concerted manner (including documenting provision of notification in response to individuals' access requests for transmission of ePHI in an unencrypted manner and has been informed of the risks associated with the transmission, receipt, and storage of unencrypted ePHI). These activities are specified in the NPRM, but they would be more in the nature of clarifications to and increased specificity of existing requirements. Because the degree of additional effort by regulated entities to meet these requirements would be dependent on multiple factors and likely to be highly variable, the additional cost is difficult to quantify.

We acknowledge that there may be a small burden associated with documenting that an individual was informed of the risks of unencrypted transmission of ePHI; however, we believe there are few requests that fall into this category. Because we do not have a basis to make an estimate, we have requested data on potential burdens associated with this proposed exception to the proposed standard for encryption in the preamble discussion of 45 CFR 164.312.

The cost of complying with the exceptions to encryption and MFA for medical devices authorized by the U.S. Food & Drug Administration for marketing may depend in part on the extent to which a regulated entity relies on legacy devices because the regulated entity may be required to adopt compensating controls. New devices are likely to have encryption and MFA built into them, not requiring compensating controls. The Department is unable to estimate the range of costs to adopt compensating controls for legacy devices because there is no reliable data to accurately assess the extent to which legacy devices are used in the United States.^[939] The Department requests comment on the number of legacy devices in use and the costs of applying compensating controls to such devices.

2. Baseline Conditions

The Security Rule, in conjunction with the Privacy and Breach Notification Rules, protects the privacy and security of individuals' PHI, that is, individually identifiable health information (IIHI). The Security Rule's protections are limited to ePHI, while the Privacy and Breach Notification Rules protect both electronic and non-electronic PHI. The Security Rule establishes standards to protect individuals' ePHI and requires reasonable and appropriate administrative, physical, and technical safeguards. The Security Rule specifies a series of administrative, physical, and technical security requirements that must be performed or implemented for regulated entities to safeguard ePHI. Specifically, entities regulated by the Security Rule must: (1) ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit; (2) protect against reasonably anticipated threats to the security and integrity of the information; (3) protect against reasonably anticipated impermissible uses or disclosures; and (4) ensure compliance by their workforce. A major goal of the Security Rule is protecting the security of individuals' health information while allowing for the development of a health information system to improve the efficiency and effectiveness of the health care system.

The Administrative Simplification provisions of HIPAA (title II) provide the Secretary of HHS with the authority to publish standards for the privacy and security of health information. The Department first proposed standards for the security of ePHI on August 12, 1998, and published a final rule on February 20, 2003. The Department modified the Security Rule in 2013. Recently, as the preamble to this NPRM discusses, changes in the health care environment and insufficient compliance by regulated entities with the existing Security Rule require the modifications proposed here.

For purposes of this Regulatory Impact Analysis (RIA), the proposed rule adopts the list of covered entities (with an updated count) and certain cost assumptions identified in the Department's Information Collection Request (ICR) associated with the HIPAA Privacy Rule to Support Reproductive Health Care Privacy (“2024 ICR”).^[940] The Department also relies on certain estimates and assumptions from the 1998 Proposed Rule ^[941] that remain relevant, the 2003 Final Rule,^[942] and the 2013 Omnibus Rule,^[943] as referenced in the analysis that follows.

The Department quantitatively analyzes and monetizes the effect that this proposed rule would have on the actions of regulated entities to: conduct a Security Rule compliance audit; provide or obtain verification of business associates' compliance with technical safeguards; notify other regulated entities when workforce members' access to ePHI is altered or terminated; notify covered entities or business associates, as applicable, upon activation of a contingency plan; complete network segmentation; disable unused ports and remove extraneous software; deploy MFA and penetration testing; update health plan documents; update policies and procedures; update workforce training; and revise business associate agreements. The Department also quantitatively analyzes the effects on group health plan sponsors for ensuring that safeguards for their relevant electronic information systems meet Security Rule standards and notifying group health plans upon activation of the plan sponsors' contingency plans.

Additionally, the Department quantitatively analyzes the benefits of the proposed modifications to regulated entities due to an expected reduction in costs of remediation of breaches and risk of breaches by regulated entities.

The Department analyzes the remaining benefits and costs qualitatively because many of the proposed modifications are clarifications of existing requirements and predicting other concrete actions that such a diverse scope of regulated entities might take in response to this rule is inherently uncertain.

Analytic Assumptions

The Department bases its assumptions for calculating estimated costs and benefits on several publicly available datasets, including data from the U.S. Census Bureau (“Census”), the U.S. Department of Labor's (DOL) Bureau of Labor Statistics, the Small Business Administration (SBA), and the Department's Centers for Medicare & ( print page 995) Medicaid Services (CMS) and Agency for Healthcare Research and Quality (AHRQ). For the purposes of this analysis, the Department assumes that employee benefits plus indirect costs equal approximately 100 percent of pre-tax wages and adjusts the hourly wage rates by multiplying by two, for a fully loaded hourly wage rate. The Department adopts this as the estimate of the hourly value of time for changes in time use for on-the-job activities.

Implementing the proposals likely would require regulated entities to engage workforce members or consultants for certain activities. The Department assumes that an information security analyst would perform most of the activities proposed in the NPRM, consistent with the existing Security Rule requirements. The Department expects that a computer and information systems manager would revise policies and procedures, a training and development specialist would revise the necessary workforce training, a lawyer would revise business associate agreements, and a compensation and benefits manager would revise health plan documents for plan sponsors. To the extent that these assumptions affect the Department's estimate of costs, the Department solicits comment on its assumptions, particularly assumptions in which the Department identifies the level of workforce member ( e.g., analyst, manager, licensed professional) that would be engaged in activities and the amount of time that particular types of workforce members spend conducting activities related to this RIA as further described below. Table 3 lists pay rates for occupations referenced in the cost estimates for the NPRM.

Table 3—Occupational Pay Rates ⁹⁴⁴

Occupation code and title	Fully loaded hourly wage	2023 Average hourly wage
15-1212 Information Security Analysts	$119.94	$59.97
13-1151 Training and Development Specialists	69.20	34.60
11-3111 Compensation and Benefits Manager	145.14	72.57
11-3021 Computer and Information Systems Managers	173.76	86.88
23-1011 Lawyers	169.68	84.84
13-1111 Management Analysts	111.08	55.54
43-0000 Office and Administrative Support Occupations	46.10	23.05

The Department assumes that most regulated entities would be able to incorporate changes to their workforce training into existing cybersecurity awareness training programs and Security Rule training rather than conduct a separate training because the total time frame for compliance from date of publication of a final rule would be 240 days.^[945]

Regulated Entities Affected

The changes proposed in this NPRM would apply to covered entities ( i.e., health care providers that conduct covered electronic transactions, health plans, and health care clearinghouses) and their business associates (including subcontractors). The Department estimates the number of covered entities to be 822,600 business establishments (see table 4). By calculating costs for establishments, rather than firms,^[946] some burdens may be overestimated because certain costs would be borne by a parent organization rather than each separate facility. Similarly, benefits and transfers would be overestimated because entity assumptions flow through to those quantifications. However, decisions about the level of an organization that is responsible for implementing certain requirements likely varies across the health care industry. The Department requests data on the extent to which certain burdens are borne by each facility versus an umbrella organization.

According to Census data,^[947] there are 954 Direct Health and Medical Insurance Carrier firms out of a total 5,822 Insurance Carrier firms, such that health and medical insurance firms make up approximately 16.4 percent of insurance firms [= 954/5,822].^[948] Also, according to Census data, there are 2,506 Third Party Administration of Insurance and Pension Funds firms and 8,375 establishments. This category also includes clearinghouses. The Department assumes that 16.4 percent of these firms service health and medical insurance because that is equivalent to the share of insurance firms that are health and medical. As a result, the Department estimates that 411 firms categorized as Third Party Administrators are affected by the proposals in this NPRM [= 2,506 × .164]. Similarly, the Department estimates that 1,374 associated establishments would be affected by the proposals in this NPRM [= 8,375 total establishments × .164]. Most of these are business associates. Based on data from the Department's HIPAA audits and experience administering the HIPAA Rules, we are aware of approximately 36 clearinghouses. See table 4 below.

There were 56,289 community pharmacies, including 19,261 pharmacy and drug store firms, operating in the U.S. in 2023.^[949] Small pharmacies generally use pharmacy services administration organizations (PSAOs) to provide administrative services, such as conducting negotiations. Based on information from industry, the Department estimates that the proposed rule would affect fewer than 10 PSAOs and we include this within the estimated 1 million business associates affected by the proposals in this NPRM.^[950] The Department assumes that ( print page 996) costs affecting pharmacies are incurred at each pharmacy and drug store establishment and each PSAO.

Table 4—Estimated Number, Type, and Size Threshold of Covered Entities

Covered Entities
NAICS code	Type of entity	Firms	Establishments	Small business administration (SBA) size threshold c (million)
524114	Health and Medical Insurance Carriers	954	5,552	$47
524292	Clearinghouses a	36	36	47
622	Hospitals	3,095	7,465	47
446110	Pharmacies b	31,671	56,289	37.5
6211-6213	Office of Drs. & Other Professionals	429,476	527,951	9-16
6215	Medical Diagnostic Laboratories & Imaging	8,714	19,477	19-41.5
6214	Outpatient Care	26,084	54,642	19-47
6219	Other Ambulatory Care	10,547	16,114	20.5-40
623	Skilled Nursing & Residential Facilities	42,421	95,175	16-34
6216	Home Health Agencies	27,433	38,040	19
532283	Home Health Equipment Rental	488	1,859	41
Total		580,9198	822,600
a  This North American Industry Classification System (NAICS) category includes clearinghouses and is titled “Third Party Administration of Insurance and Pension Funds.” The number of clearinghouses is based on the Department's research.
b  Number of pharmacies is taken from industry statistics.
c   See “Table of Small Business Size Standards,” U.S. Small Business Administration (Mar. 17, 2023), https://www.sba.gov/​sites/​sbagov/​files/​2023-06/​Table%20of%20Size%20Standards_​Effective%20March%2017%2C%202023%20%282%29.pdf. The SBA size thresholds are discussed in Section V.C. Regulatory Flexibility Act—Small Entity Analysis of this NPRM.

The Department also estimated the percentage of rural and urban health care providers by matching health care provider data from CMS,^[951] Health Resources & Services Administration,^[952] and the Statistics of U.S. Businesses (SUSB) ^[953] with county population data from the U.S. Census Bureau.^[954] We determined whether a health care provider was rural or urban based on OMB's standards for delineating metropolitan and micropolitan statistical areas.^[955] Consistent with OMB's standard, we considered a county to be rural if it has fewer than 50,000 inhabitants.^[956] This includes micropolitan areas (towns and cities between 10,000 and 49,999) and counties outside of metropolitan statistical areas and micropolitan areas. Based on this analysis, we estimate that 7-8 percent of health care providers operate in rural areas.

Estimated Number and Type of Business Associates

The Department adopts the estimate of approximately 1,000,000 business associates (including subcontractors) as stated in the 2024 ICR and the 2013 “Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules Under the Health Information Technology for Economic and Clinical Health [HITECH] Act and the Genetic Information Nondiscrimination Act, and Other Modifications to the HIPAA Rules” final rule.^[957] We considered whether to increase this figure in our updates but did not do so because many business associates serve multiple covered entities. We lack sufficient data to estimate the number of such businesses more precisely, but we believe that the number of business associates is highly dynamic and dependent on multiple market factors, including expansion and consolidation among various lines of business, changing laws and legal interpretations, and emerging technologies. We include subcontractors of business associates within our estimate because they are business associates of business associates.

The Department welcomes comments on the number or type(s) of regulated entities that would be affected by the proposals in this proposed rule and the extent to which they may experience costs or other burdens not already accounted for in the cost estimates. The Department also requests comment on the number of health plan documents that would need to be revised, if any. The Department additionally requests detailed comment on any situations, other than those identified here, in which covered entities or business associates would be affected by the proposals in this rulemaking.

Health Plan Sponsors

Within this NPRM, the Department is for the first time including estimates of health plan sponsors' potential costs of compliance with specific ( print page 997) administrative, physical, and technical safeguards of the Security Rule. The Department relied on data from AHRQ and the U.S. Census to estimate the number of firms offering group health plans (1.9 million),^[958] and multiplied that by the percentage that offer at least one self-insured plan to calculate the number of plan sponsors that would be likely to receive ePHI and be subject to the requirements of 45 CFR 164.314(b) [1,943,484 × .382 = 742,411]. We solicit comments on whether group health plans or third-party administrators address any Security Rule requirements for plan sponsors, so the plan sponsors would not have an additional burden or would have a smaller burden than estimated below.

Individuals Affected

The number of individuals potentially affected by the proposed changes to the Security Rule includes most of the United States population (approximately 337 million), specifically those who have received any health care in the past seven years and whose ePHI is likely created, received, maintained, or transmitted by a regulated entity. Statistics about the number of individuals affected by breaches of PHI provide insight into known instances where safeguards were breached, although the effects of the Security Rule extend farther than that, to all ePHI. Data from the 2022 Annual Report to Congress on Breaches of Unsecured Protected Health Information for Calendar Year 2022 ^[959] revealed nearly 42 million individuals affected by breaches of PHI in that year. Third-party sources reported approximately 133 million individuals affected by health care breaches in 2023.^[960] According to UnitedHealth Group, the 2024 breach of its clearinghouse subsidiary Change Healthcare may have affected approximately one-third of the U.S. population, or 112 million individuals.^[961] The Department believes that the range of individuals potentially affected by the proposed regulatory changes would be from 42 million to 337 million.

HIPAA Breach Data

The Department has reported HIPAA/HITECH breach data annually since 2009. Table 5 shows the data as reported to Congress for the past five years. We relied on this data, combined with breach cost data from industry sources, to analyze the potential savings of the NPRM.

Table 5—Breaches of PHI

Year	Small breaches (fewer than 500 affected individuals)		Large breaches (500+ affected individuals)		Total
	Breach count	Affected individuals	Breach count	Affected individuals	Breach count	Affected individuals
2018	63,098	296,948	302	12,196,601	63,400	12,493,549
2019	62,771	284,812	408	38,732,966	63,179	39,017,778
2020	66,509	312,723	656	37,641,403	67,165	37,954,126
2021	63,571	319,215	609	37,182,558	64,180	37,501,773
2022	63,966	257,105	626	41,747,613	64,592	42,004,718

3. Costs of the Proposed Rule

Below, the Department provides the basis for its estimated quantifiable costs resulting from the proposed changes to specific provisions of the Security Rule. Many of the estimates are based on assumptions formed through OCR's experience with compliance and enforcement and accounts from stakeholders. For each cost, the Department provides its main estimate, as well as additional high and low estimates for some costs to account for any uncertainty in the compliance approach of regulated entities.

All estimates in this section are based on subject matter expertise. The Department requests information or data points from commenters to further refine its estimates and assumptions.

a. Costs Associated With Conducting a Security Rule Compliance Audit

The Department estimates that all regulated entities would need to conduct a Security Rule Compliance Audit because this would be a new requirement under proposed 45 CFR 164.308(a)(14). Although some regulated entities have mistakenly conducted such an audit in lieu of a risk analysis, the Department believes that costs for the compliance audit as a separate requirement should be attributed to the proposed changes in the NPRM. Further, because this would be an annual requirement, the Department is including this as a recurring cost. The Department estimates that regulated entities would need an average of 2 hours of labor by an information systems analyst to conduct the compliance audit, based on the assumption that regulated entities have already documented Security Rule compliance activities as currently required. This would result in total estimated costs of $437,205,288 [= 1,822,600 regulated entities × 2 hours × $119.94]. The respective low and high estimates would be 0.25 and 2.5 hours of information systems analyst labor, resulting in respective total estimated costs of $54,650,6611 [= 1,822,600 regulated entities × 0.25 hours × $119.94] and $546,506,610 [= 1,822,600 regulated entities × 2.5 hours × $119.94]. ( print page 998)

b. Estimated Costs From Adding a Requirement for Business Associates to Analyze Compliance With Technical Safeguards

For proposed 45 CFR 164.308(b), the Department estimates that business associates that handle ePHI would need to spend an average of 2 hours (with a low estimate of 0.25 hours and high estimate of 2.5 hours) analyzing how their cybersecurity measures comply with the proposed requirements for technical safeguards and producing a verification report for covered entities at the hourly wage rate of an information security analyst. This estimate assumes that business associates have already documented existing safeguards, policies, and procedures, so that the costs attributable to the new requirement are incremental and would total approximately $239,880,000 [1 million business associates × 2 hours × $119.94], with a low estimate of $29,985,000 [1 million business associates × 0.25 hours × $119.94] and high estimate of $299,850,000 [1 million business associates × 2.5 hours × $119.94].

c. Costs Arising From Covered Entities and Business Associates Obtaining Verification From Business Associates of Compliance With Technical Safeguards

Under 45 CFR 164.308(b), the Department further estimates that each covered entity would need to spend an average of 30 minutes (with 15 minutes as a low estimate and 90 minutes as a high estimate) requesting and obtaining compliance reports from its business associates about their deployment of technical safeguards required by the Security Rule at the hourly wage of an information security analyst. This assumes that in most instances, business associates would produce the required verification for covered entities without being prompted by a request because they would be required to do so by the Security Rule, as proposed in the NPRM. It further assumes that covered entities have readily available means of contacting business associates, such as via email, and that the contact could be a single email draft sent in a batch. The average time burden per entity depends on verification frequency, likely influenced by entities' average number of business associates and how frequently entities change business associates. The low estimate assumes that entities verify less frequently, whereas the high estimate assumes entities verify more frequently. At the wage rate of an information security analyst, this would result in estimated total costs for covered entities of $49,331,322 [= 822,600 covered entities × 0.5 hours × $119.94], with a low estimate of $24,665,661 [= 822,600 covered entities × 0.25 hours × $119.94] and high estimate of $147,993,966 [= 822,600 covered entities × 1.5 hours × $119.94].

The proposed requirement to obtain verification of compliance with technical safeguards also would apply to business associates with respect to their subcontractors. However, we believe that a much smaller number of business associates rely on subcontractors compared to the number of covered entities that rely on business associates to conduct activities on their behalf. Thus, we estimate that, on average, business associates would need 5 minutes annually to obtain verification from their subcontractors that the subcontractors have complied with technical safeguards as required by the Security Rule. The estimate includes only the time needed for business associates to send a mass email to subcontractors because we have already addressed the burden on business associates of producing the verification in the previous section and that estimate includes burdens on subcontractors. The high estimate for this activity would be an average of 15 minutes per business associate, and a low estimate would be for business associates to 2 minutes on this activity. At the wage rate of an information security analyst, this would add estimated total costs for business associates of $9,995,000 [= 1,000,000 business associates × 0.083 hours × $119.94], with a high estimate of $29,985,000 [= 1,000,000 business associates × .25 hours × $119.94].

d. Cost Related to Notification of Termination or Change of Workforce Members' Access to ePHI

The Department estimates that regulated entities are likely to incur additional costs to implement a process to notify other regulated entities when a workforce member's access to ePHI is terminated or changed under proposed 45 CFR 164.308(a)(9)(ii). This estimate assumes that notifications will take an average of 1 hour annually per regulated entity. This results in new estimated costs totaling $84,021,860 [= 1,822,600 regulated entities × 1 hour × $46.10].^[962]

e. Cost Related to Regulated Entities Deploying Multi-Factor Authentication

The Department estimates that, on average, regulated entities would have an information security analyst spend 1.5 hours deploying MFA, as specifically required under proposed 45 CFR 164.312(f)(2)(ii). This would be a one-time, first-year burden that includes an average of 30 minutes for a regulated entity to select an MFA solution that allows them to meet the requirements of the proposal without creating workflow disruptions or delays. This estimate would vary depending on how prevalent MFA is in the industry when and if the requirements of the NPRM are finalized. As a widely accepted information security practice, the Department believes that many large entities have already deployed MFA and the costs range from zero to only a few dollars per user. The low estimate would be 01 hours on average (assuming that many entities already have some form of MFA), and the high estimate would be 1.75 hours (assuming that few entities have MFA). At the loaded wage rate of an information security analyst, the total estimated cost would be $327,903,966 [= 1,822,600 regulated entities × 1.5 hours × $119.94], with a low estimated total of $218,602,644 [= 1,822,600 regulated entities × 1 hour × $119.94] and a high estimated total of $382,554,627 [= 1,822,600 regulated entities × 1.75 hours × $119.94]. The Department applies this cost in the first year only because minimal additional labor is needed to maintain this safeguard once it has been deployed.

f. Costs Related to Network Segmentation

The Department believes that most large regulated entities and many medium-sized regulated entities have segmented their information networks to some degree; however, additional actions may be needed to more fully protect ePHI as required under proposed 45 CFR 164.312(a)(2)(vi). Further, small entities may not have been aware of the importance of segmenting networks or taken steps to segment their networks. The Department estimates that each regulated entity would spend an average of 4.5 hours to set up network segmentation in the first year of compliance with a final rule (with a low estimate of 4 hours and a high estimate of 5 hours) at the hourly wage of an information security analyst. The Department further assumes that in the following years, the burden to maintain the segmented network would be minimal and incorporated into the maintenance requirements. The total first year estimated cost of the network segmentation requirement would be $983,711,898 [= 1,822,600 regulated entities × 4.5 hours × $119.94] with a low estimated total of $874,410,576 [= 1,822,600 regulated entities × 4 hours × ( print page 999) $119.94] and a high estimate of $1,093,013,220 [= 1,822,600 regulated entities × 5 hours × $119.94].

g. Cost Related to Disabling Ports and Removing Extraneous Software

The Department believes that large regulated entities have already disabled unused network ports and removed extraneous software as part of existing configuration requirements. However, the Department believes that small and medium-sized regulated entities are less likely to have performed these actions and thus would incur a new burden to implement these aspects of configuration management proposed at 45 CFR 164.312(c)(2)(ii) and (iv). The Department estimates that 629,796 establishments are owned by small and medium-sized covered entities,^[963] which is approximately 76.56 percent of all covered entities [= 629,796/822,600]. The Department applies that percentage to the estimated number of business associates [= 0.7656 × 1,000,000] to arrive at the estimated number of regulated entities with quantifiably increased burdens from these proposed requirements to disable unused ports and remove extraneous software. We estimate that for these 1,395,396 regulated entities [= 629,796 covered entities + 765,600 business associates], an average annual burden of 30 minutes would be needed at the wage rate of an information security analyst to make needed changes to configuration management, specifically disabling unused ports and removing extraneous software. This would result in estimated total cost increases of $83,681,898 [= 1,395,3960 regulated entities × 0.5 hours × $119.94], with a low estimate of $41,840,949 [= 1,395,396 regulated entities × 0.25 hours × $119.94] based on an estimated annual burden of 15 minutes per affected entity and a high estimate of $109,301,322 [= 1,822,600 regulated entities × 0.50 hours × $119.94] based on an estimated annual burden of 30 minutes for all regulated entities.

h. Costs Related to Regulated Entities Conducting Penetration Testing

The Department estimates that each regulated entity would spend an average of 3 hours conducting penetration testing (with a low estimate of 2 hours and a high estimate of 10 hours) at the hourly wage of an information security analyst. The Department expects that there might be a high degree of variability between entities depending on their size and technological sophistication. Large entities have more endpoints to test, and thus have greater exposure. The Department also believes there is room for significant variability in the effort that regulated entities may apply to this activity. At the wage rate of an information security analyst, this would result in estimated total annual costs for regulated entities of $655,807,932 [= 1,822,600 regulated entities × 3 hours × $119.94], with a low estimated total of $437,205,288 [= 1,822,600 regulated entities × 2 hours × $119.94] and high estimated total of $2,186,026,440 [= 1,822,600 regulated entities × 10 hours × $119.94].

i. Costs Arising From Reporting Contingency Plan Activation

The Department estimates that business associates would need to notify other regulated entities in the event that they activate their contingency plan once business associate agreements are revised according to proposed 45 CFR 164.314(a)(2)(i)(D). The Department believes this is unlikely to occur more frequently than once per year and that the time to do so would be minimal because the proposed requirement does not specify the means or scope of such notification. The Department estimates that business associates would need an average of 30 minutes (with 15 minutes as a low estimate and 45 minutes as a high estimate) to report to other regulated entities, as applicable, when their contingency plan is activated at the wage rate of an information security analyst for a total annual cost of $59,970,000 [= 1,000,000 business associates × 0.5 hours × $119.94], with a low estimated total of $29,985,000[= 1,000,000 business associates × 0.25 hours × $119.94] and high estimated total of $89,955,000 [= 1,000,000 business associates × 0.75 hours × $119.94].

j. Revised Health Plan Documents

The Department estimates that health care insurers and third-party administrators would need to revise health plan documents to reflect that health plan sponsors that receive ePHI (that is not limited to summary health information or disenrollment information) are protecting ePHI with the administrative, physical, and technical safeguards detailed in the Security Rule, as proposed. These 6,162 entities collectively would be responsible for updating approximately 742,411 health plan documents at the wage rate of a compensation and benefits manager. The Department's estimate assumes that on average each plan document requires 30 minutes to update for a total estimated cost of $53,876,766 [1742,411 × 0.5 hours × $145.14]. The Department has attributed these costs solely to health plans and not health plan sponsors because the health plan is the regulated entity.

k. Estimated Costs for Developing New or Modified Policies and Procedures

The Department anticipates that regulated entities would need to develop new or modified policies and procedures for the proposed new requirements to obtain or provide verification of business associates' compliance with the Security Rule's requirements for technical safeguards, conducting a Security Rule compliance audit, and reporting the activation of a contingency plan, as well as other proposed changes, depending on the regulated entities' existing policies and procedures. The Department estimates that the costs associated with developing such policies and procedures would be the labor of a computer and information systems manager for an average of 3.5 hours (with 2.5 hours as a low estimate and 6 hours as a high estimate, depending on the number of entities with written policies and procedures, and their degree of specificity). This would result in total annual costs of $1,108,432,416 [= 1,822,600 regulated entities × 3.5 hours × $173.76], with a low estimated total of $791,737,440 [= 1,822,600 regulated entities × 2.5 hours × $173.76] and high estimated total of $1,900,169,856 [= 1,822,600 regulated entities × 6 hours × $173.76]. The existing rule requires updates to policies and procedures in response to environmental or operational changes affecting the security of the ePHI, and as a result, the Department is estimating additional costs for new policies related to this proposed rule as an incremental increase.

l. Costs Associated With Training Workforce Members

The Department anticipates that regulated entities would be able to incorporate new content into existing Security Rule training programs and that the costs associated with doing so would be attributed to the labor of a training specialist for an estimated 2 hours for total annual costs of $252,247,840 [= 1,822,600 regulated entities × 2 hours × $69.20]. The low estimate for this activity is $126,123,920 [= 1,822,600 regulated entities × 1 hour × $69.20], and the high estimate is $378,371,760 [= 1,822,600 regulated entities × 3 hours × $69.20]. Many of the changes in the NPRM require the ( print page 1000) adoption of standard cybersecurity practices as applied specifically to address the confidentiality, integrity, and availability of ePHI, so we expect that an information security analyst would be familiar with this content. These estimated costs would address any required revisions to training for workforce members within the first year of compliance with a final rule. Any further recurring component is likely to be implemented into regularly scheduled employee training and thus would not be directly attributable to the proposals in this NPRM.

m. Revising Business Associate Agreements

The NPRM proposes to provide a transition period in proposed 45 CFR 164.318 for regulated entities to revise business associate agreements to comply with the proposed changes to the requirements of the Security Rule. The proposed transition period would allow regulated entities to revise existing agreements by the earlier of the contract renewal date that falls after the compliance date of a final rule, or within one year of the rule's effective date. For a large share of existing agreements, this would allow regulated entities to complete the revisions on a rolling basis according to the dates they are renewed. The Department estimates that 1,822,600 ^[964] business associate agreements would need to be revised if this NPRM is adopted and that, on average, the portion of this activity that results from the rule's modifications would take an hour of a lawyer's time for each regulated entity. This would result in annual costs of $309,258,768 [= 1,822,600 regulated entities × 1 hour × $169.68]. The Department recognizes that this estimate may not fully account for all revised business associate agreements. However, the Department believes that in some instances, one hour of time is more than would be needed. We also believe it is likely that, for some regulated entities, a professional other than a lawyer would be responsible for the revised agreements at a lower hourly wage. For some large business associates, the Department believes that a single agreement is used for most of its customers. The Department's estimates assume that most agreements would be revised within the first year and accounts for all of them within that time period. This would be considered a one-time cost; in other words, it is not carried over into future years. As with all the estimates in this NPRM, the Department invites comments about the assumptions underlying the proposed cost projections.

n. Plan Sponsors' Obligations

Proposed 45 CFR 164.314(b)(2) would mandate that group health plan documents require their health plan sponsors who receive ePHI that is not limited to summary health information or enrollment or disenrollment information to deploy the administrative, physical, and technical safeguards for ePHI required by the Security Rule and notify their group health plans upon activation of the plan sponsors' contingency plan. Currently, plan documents must require such health plan sponsors to have safeguards in place, but not necessarily the safeguards specified in the Security Rule.^[965] The Department estimates that an additional 52.42 hours of labor would be needed for each affected health plan sponsor to bring its security safeguards for ePHI into compliance with the Security Rule standards and to notify group health plans when its contingency plan is activated, over and above the actions attributable to safeguards already in place for ePHI and for sponsors' electronic information systems generally. The Security Rule compliance activities attributed to group health plan sponsors are shown in table 7, below.

Most compliance activities would be performed by a workforce member at the hourly wage rate of an information security analyst ($119.94), while documentation of maintenance would be performed at the rate of a management analyst ($111.08) and notification of termination or change of workforce members' access to ePHI would be performed by an office administrative assistant ($46.10). This would result in estimated total first year costs for health plan sponsors of $4,658,781,219 as shown in detail in table 7.

o. Total Quantifiable Costs

The Department summarizes in tables 6 and 7 the estimated costs that regulated entities (approximately $4,655 million) and plan sponsors (approximately $4,659 million), respectively, would experience in the first year of implementing the proposed regulatory changes. The Department anticipates that these costs would be for the following activities: conducting a Security Rule compliance audit; obtaining verification of business associates' and subcontractors' compliance with technical safeguards; providing verification of business associates' compliance with technical safeguards; providing notification of termination or change of workforce members' access to ePHI; deploying MFA and penetration testing; segmenting networks; disabling unused ports; removing extraneous software; notifying covered entities or business associates, as applicable, upon activation of a contingency plan; and updating health plan documents, policies and procedures, workforce training, and business associate agreements. These costs would also include health plan sponsors deploying safeguards for their relevant electronic information systems to meet Security Rule standards and notifying group health plans upon activation of a plan sponsor's contingency plan.

Table 6—First Year Cost Estimates for Regulated Entities' Proposed Compliance Obligations  ^a

Compliance activities	Burden hours × frequency	Respondents	Wage rate	Total annual cost (millions)
Security Rule Compliance Audit	2 × 1	1,822,600 Regulated Entities	$119.94	$437
BA Verification of Technical Safeguards	2 × 1	1,000,000 Business Associates	119.94	240
Obtain BA Compliance Verification	.5 × 1	822,600 Covered Entities	119.94	49
Obtain Subcontractors' Compliance Verification	.083 × 1	1,000,000 Business Associates	119.94	10
Notification of Workforce Members' Termination of access to ePHI	1 × 1	1,822,600 Regulated Entities	46.10	84
( print page 1001)
Multi-factor Authentication	1.5 × 1	1,822,600 Regulated Entities	$119.94	$328
Network Segmentation	4.5 × 1	1,822,600 Regulated Entities	119.94	984
Configuration Management	.5 × 1	1,395,396 Regulated Entities	119.94	84
Penetration Testing	3 × 1	1,822,600 Regulated Entities	119.94	656
Notification of Contingency Plan Activation	.5 × 1	1,000,000 Business Associates	119.94	60
Update Health Plan Documents	.5 × 120	3,102,851 Health Plan Documents	145.14	54
Update Policies and Procedures	3.5 × 1	1,822,600 Regulated Entities	173.76	1,108
Update Workforce Training	2 × 1	1,822,600 Regulated Entities	69.20	252
Revise Business Associate Agreements	1 × 1	1,822,600 Regulated Entities	169.68	309
Total Annual Cost Burden				4,655
a  These represent first year estimated costs and are rounded.

The Department presents the estimated cost of health plan sponsors' compliance with the proposed new requirements in table 7 below.

Table 7—First Year Cost Estimates of Health Plan Sponsors' Proposed Compliance Obligations  ^a

Compliance activities	Burden hours × frequency	Respondents	Wage rate	Total annual cost (millions)
Risk Analysis—Documentation	5 × 1	742,411 Plan Sponsors	$119.94	$445
Information System Activity Review—Documentation	.75 × 12	742,411 Plan Sponsors	119.94	801
Ongoing Education	.17 × 12	742,411 Plan Sponsors	119.94	178
Security Incidents (other than breaches)—Documentation	2 × 12	742,411 Plan Sponsors	119.94	2,137
Contingency Plan—Testing and Revision	2 × 1	742,411 Plan Sponsors	119.94	178
Contingency Plan—Criticality Analysis	.5 × 1	742,411 Plan Sponsors	119.94	45
Notification of Workforce Members' Termination of ePHI Access	.25 × 1	742,411 Plan Sponsors	46.10	9
Maintenance Records	.5 × 12	742,411 Plan Sponsors	111.08	495
Multi-factor Authentication	1.5 × 1	742,411 Plan Sponsors	119.94	133
Configuration Management	.5 × 1	742,411 Plan Sponsors	119.94	45
Penetration Testing	2 × 1	742,411 Plan Sponsors	119.94	178
Notification of Contingency Plan Activation	.17 × 1	742,411 Plan Sponsors	119.94	15
Total Annual Cost Burden				4,659
a  These represent first year estimated costs and are rounded.

Together, regulated entities' and affected health plan sponsors' estimated first year costs of compliance with the proposals in the NPRM would be approximately 9,314 million (or $9 billion).

p. Costs Borne by the Department

The covered entities that are operated by the Department would be affected by the changes in a similar manner to other covered entities, and such costs have been factored into the estimates above. The Department has not identified other costs to the Department related to the changes in the NPRM. A reduction in the number of large breaches (affecting 500 or more individuals per incident) would benefit the Department by enabling it to focus its resources on a smaller number of breach investigations, and potentially resolve such investigations more quickly.

4. Benefits of the Proposed Rule

a. Quantitative Analysis of Benefits

A key goal of strengthening the cybersecurity posture of regulated entities is to reduce the number and severity of security incidents, including breaches of ePHI. The Department believes that compliance with the proposed changes, which align with industry guidelines and best practices, would benefit regulated entities by reducing the cost of breaches. Although the costs of implementing the proposed cybersecurity measures would be significant, the costs of responding to breaches of ePHI are much higher. According to industry data, the average cost of a health care breach in 2023 rose to $10.93 million, the highest among all industries studied,^[966] and the per record cost of a breach involving personally identifiable information (across all industries) was $183.^[967] These costs include detection and investigation activities, notification activities, post-breach response activities, and activities attempting to minimize the loss of business. Thus, the benefits of the proposed rule would be to reduce the harms of health care breaches described in the preamble. The Department believes that implementing the changes in the NPRM would reduce both the incidence of breaches in health care and the costs of mitigating breaches when they occur.

The Department also analyzed the potential cost savings of proposals that ( print page 1002) correspond to major factors affecting the costs of large breaches as identified in published reports.^[968] The Department estimates that, at a minimum, performing the following actions would quantifiably reduce costs: (1) encryption; (2) penetration testing; (3) requiring MFA and notification of termination of access to ePHI; (4) increasing employee training; and (5) reducing noncompliance with regulations. These factors would account for an estimated 23.6 percent decrease in large breach costs.^[969] For health care breaches, this corresponds to an estimated cost savings of $2.6 million per large breach in high incidence years, and $2.1 million per large breach in low incidence years.

Non-Quantitative Analysis of Benefits

A fundamental benefit of the proposed rule would be to decrease the effects of breaches on individuals who are the subjects of ePHI, namely patients and health plan members. Breaches of ePHI may cause harm to individuals in many ways, including loss of reputation and personal dignity and financial and medical fraud, which may result in false debts, impaired credit, and even health threats from misuse of health insurance credentials by another individual. “[H]ealthcare data, which includes medical histories and personal identification, can last a lifetime. The information collected can be used for ransom, to commit tax frauds, to provide supporting disability documentation, to send fake bills to insurance providers, to obtain healthcare, prescription drugs, medical treatment, and to obtain government benefits like Medicare and Medicaid.” ^[970] Hackers can use stolen personal, medical, and financial data to take out a bank loan in the victim's name and change direct deposit information in payroll systems, allowing them to steal wages as well.^[971] In addition, medical identity fraud can impact the victim's credit score and health insurance premiums, and may result in unexpected legal fees.^[972] Medical identity fraud also enables thieves to obtain medical treatment using the victim's stolen ePHI. This can lead to the thief's medical conditions being incorporated into the victim's medical records and impacting the victim's ability to receive appropriate medical treatment based on accurate records in the future, or any care at all depending on whether the thief has exhausted the victim's insurance benefits.^[973] Overall, recovering compromised ePHI and addressing the consequences of breached information can be a long and arduous process that can cost victims large amounts of time, energy, and money.^[974]

Breaches of ePHI maintained by health care systems can also pose a threat to the medical well-being of affected individuals. Cyberattacks on health care organizations can include the deployment of malware that compromises the function of both internal and external medical devices. Such software can alter the dosages of sensitive medicines or shut down devices while they are in use, thus affecting patient care.^[975] Some of the medical devices that are vulnerable to malicious software attacks include insulin pumps and cardiac implant devices.^[976] The consequences of a cyberattack on such a medical device can be fatal.

Cyberattacks on relevant electronic information systems also hinder the efficiency of hospitals and limit the quality of care provided to patients. Breaches of relevant electronic information systems negatively affect the routine functions of health care organizations. They can affect the availability of ePHI and relevant electronic information systems and redirect critical resources from patient care to addressing the cybersecurity attack. A 2020 cyberattack on a large covered entity disrupted communication and clinician access to medical records, including to individualized chemotherapy plan templates and tools for communicating during treatment preparation and delivery.^[977] In the first week following the attack, the hospital's ability to provide critical outpatient care was reduced by 40 percent and infusion visit volume decreased by 52 percent. Many patients had to be transferred to other sites to minimize delays in receiving critical medications. The effects of this data breach are not unique to this provider. There is evidence that cyberattacks on health care organizations decrease the number of patients they are able to treat in a given day and staff utilization.^[978] Decreases in efficiency and number of treated patients also cause health care facilities to lose revenue because of their inability to provide care during a cybersecurity event.

Similar to the effects of breaches of ePHI on individuals, health care organizations and facilities also experience reputational and financial impacts because of cybersecurity attacks. Hospitals can lose the community's trust and be subject to lawsuits from individuals whose data was compromised.^[979] Organizations that experience cybersecurity attacks can experience reputational harm and other monetary costs, such as those associated with providing breach notifications, paying fines to regulators and damages to individuals, and providing credit monitoring and identity theft-related services.^[980] The harm to an organization's reputation is difficult to quantify, but it can also affect the quality of care administered to individuals.^[981] Privacy and security of ePHI are paramount to individuals feeling safe and at ease sharing their IIHI with clinicians. Security breaches can negatively impact a patient's confidence in a health care organization if they believe their information and privacy may be compromised. This can cause them to delay seeking treatment or ( print page 1003) withhold information from health care practitioners, ultimately compromising the decision-making capacity of their health care provider to administer the best quality of care.^[982] Decreasing the number and scope of health care breaches would reduce the harms of such breaches and would be a significant benefit of the proposals in the NPRM.

5. Comparison of Benefits and Costs

Key inputs to the estimation of costs of this proposed rule include the numbers of regulated entities and health plan sponsors. The Department has not previously quantified the costs of Security Rule compliance for health plan sponsors because the existing requirements are for plan documents to require such sponsors to implement administrative, physical, and technical safeguards, but not necessarily to comply with the specific requirements of the Security Rule. Therefore, the proposed requirement to comply with the proposed changes to the Security Rule, along with the number of affected plan sponsors (approximately 740,000), results in a significant increase in overall cost estimates compared to the existing rule. The benefits of improved security for ePHI accrue to individuals, regulated entities, and health plan sponsors and are significant. The Department has discussed the benefits above.

The Department seeks to reduce the risk and mitigate the effects of breaches of ePHI and related information systems through the proposals included in this NPRM. Because the frequency and magnitude of cybersecurity events are inherently difficult to predict, we chose to conduct a break-even analysis in lieu of a cost savings analysis. The Department solicits comments with any information and data on the incidence and negative consequences of cybersecurity breaches.

The Department examined two different data points: the annual number of individuals affected by health care breaches, and the annual number of large breaches. Additionally, the Department considered a high and a low baseline based on the number of breaches and affected individuals per year. The Department calculated the high baseline as the average of the three highest values in the 6 years of available data (2018 to 2023, shown in table 8), and the low baseline as the average of the three lowest values.

Table 8—Data on Breaches of e PHI

Breach years	Affected individuals for large breaches a	Cost b per record 983
2018	12,493,549	$488
2019	38,732,966	504
2020	37,641,403	476
2021	37,182,558	502
2022	41,747,613	477
2023	113,173,613	463
	Number of large breaches (500+ individuals)	Cost per breach
2018	302	12,012,809
2019	408	7,582,508
2020	656	8,273,537
2021	609	10,241,897
2022	626	10,468,138
2023	725	10,930,000
a  The numbers of affected individuals and numbers of large breaches are contained in the Reports to Congress on Breaches of Unsecured Protected Health Information for years 2018-2022, https://www.hhs.gov/​hipaa/​for-professionals/​compliance-enforcement/​reports-congress/​index.html. Data for 2023 is contained in OCR's breach portal, “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,” Office for Civil Rights, U.S. Department of Health and Human Services, https://ocrportal.hhs.gov/​ocr/​breach/​breach_​report.jsf.
b  The cost per record and cost per breach are based on estimates for health care breaches from the annual IBM Security and Ponemon Institute Costs of a Data Breach Reports for years 2018-2023. See “Cost of a Data Breach Report 2023,” IBM Security, p. 10, 13 (July 24, 2023), available at https://www.ibm.com/​reports/​data-breach. Because only general breach costs were available for the 2020-2023 period, the Department adjusted those by multiplying them by the average of the ratios of health care-specific to overall breach costs for the years for which both data points were available (2018, $408/$148 and 2019, $429/$150). All dollar values were converted to 2023 dollars using the seasonally adjusted GDP Implicit Price Deflator, https://fred.stlouisfed.org/​series/​GDPDEF/​.

The high baseline used 669 breaches and a total of 71 million individuals affected, and the low baseline used 440 breaches and 29 million individuals affected.^[984] The high baseline represents years with higher incidence of breaches, whereas the low baseline represents years with lower incidence.

For each data point, the Department calculated the number of breaches or affected individuals by which the affected universe would have to decrease for the proposed rule to fully offset the annualized costs of regulated entities.^[985] Table 9 and the discussion that follows analyses the costs and cost savings based on the number of individuals affected by breaches in a year and the cost per individual's ePHI or medical record.

( print page 1004)

Table 9—Break-Even Thresholds by Number of Affected Individuals

Baseline	Affected individuals	Regulated entities NPRM costs	Unit cost (per individual record)	Break-even threshold (NPRM cost ÷ unit cost)	Percent decrease (threshold ÷ affected) × 100
High	64,551,397	$2,251,258,305	$498	4,521,423	7
Low	29,006,854				16.4

The analysis in table 9 suggests that this NPRM would break even (cost savings would match monetized costs incurred) if the number of affected individuals is reduced by approximately 4.5 million. In years with a high incidence of breaches, this would be a reduction of approximately 7 percent, and in low-incidence years this would be a decrease of 16.4 percent. Thus, if the proposed changes in the NPRM reduce the number of affected individuals by 7 to 16 percent, the rule would pay for itself. Alternatively, the same cost savings may be achieved by lowering the cost per affected individual's ePHI by 7 percent ($35) and 16 percent ($82), respectively.

Table 10 analyzes the potential cost savings for regulated entities based on the annual number of large breaches of ePHI and the cost per breach, as shown below.

Table 10—Break-Even Thresholds by Number of Large Breaches

Baseline	Breaches	NPRM cost for regulated entities	Unit cost (per breach)	Break-even threshold (NPRM cost ÷ unit cost)	Percent decrease (threshold ÷ breaches) × 100
High	669	$2,251,258,305	$11,136,982	202	30.1
Low	440				58.9

In table 10, the Department assumes that the average cost per breach in industry reports ($11.1 million, calculated as the average of the three highest values in table 9, adjusted for inflation) refers to large breaches of ePHI . The analysis in table 10 suggests that the NPRM would break even if the annual number of large breaches is reduced by approximately 202. In high-incidence years, this would be a reduction of approximately 30 percent, and in low-incidence years, this would be a decrease of 59 percent. Alternatively, the same cost savings may be achieved by lowering the cost per breach by 30 percent ($3.4 million) and 9 percent ($6.6 million), respectively.

B. Regulatory Alternatives to the Proposed Rule

The Department welcomes public comment on any benefits or drawbacks of the following alternatives it considered, but did not propose, while developing this proposed rule. We also request comment on whether the Department should reconsider any of the alternatives considered, and if so, why.

No Changes to the Security Rule

We considered not proposing revisions to the Security Rule. However, the Department believes that not revising the Security Rule would result in continued increases in both the number and size of breaches. Such increases would result in an exponential increase in costs as shown in table 8 above. If the modifications to the Security Rule result in even modest improvements to the security of ePHI, the reduction in the number and/or size of breaches would reduce the overall costs associated with breaches, including the costs of mitigating harm resulting from such breaches.

Email Security

The Department considered proposing a separate standard for regulated entities to secure email transmissions. In the Department's Cybersecurity Performance Goals,^[986] the Department identifies email security as an essential goal for reducing risk from common email-based threats such as email spoofing, phishing, and fraud. Therein, the Department points to basic email protection controls identified in the Health Industry Cybersecurity Practices, such as spam/virus checking and real-time deny lists, as well as strategies that may be deployed across small, medium, and large organizations, including MFA for email access, email encryption, workforce education, and advance tooling ( e.g., URL click protection via analytics, attachment sandboxing).^[987]

The Department is aware of the threat that email poses to the information systems of regulated entities and to the confidentiality, integrity, and availability of ePHI.^[988] However, the Department believes that it is important that the Security Rule remain technology-neutral and that the security measures we propose in this NPRM apply to a regulated entity's information systems broadly, including email programs. For example, in this NPRM, the Department proposes to require regulated entities to encrypt all ePHI at rest and in transit and proposes a transmission security standard in which regulated entities would be required to deploy technical controls to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.^[989] Therefore, the Department believes it is unnecessary to promulgate a separate standard for email security. Because the other technical controls, such as encryption and MFA, are already incorporated into the requirements that would protect relevant electronic information systems, the Department believes that adopting a separate secure email standard would duplicate costs without creating a net benefit.

( print page 1005)

Additionally, the Department considered whether to heighten the existing expectation ^[990] for regulated entities to inform individuals before transmitting ePHI to the individual via unencrypted email in response to a request for access under 45 CFR 164.524 by this means. We considered whether to require such notification for different types of requests, such as different categories of PHI ( e.g., billing, lab results, etc.), determining whether the individual had already received such notice, or providing notification upon each disclosure. Instead, the Department has proposed to clarify that notification must be provided for each request made by the individual under the individual right of access at 45 CFR 164.524 for their ePHI to be transmitted via unsecure email. We believe that requiring a regulated entity to determine whether the individual had already received such notification would be more burdensome than incorporating the notification into the access request process, and instead, have proposed. We estimate that this could increase burdens for providing access via unsecure means by approximately one minute per request of this type. We lack data to estimate the number of requests for access via unsecure means.

Small and Rural Health Care Providers

Consistent with the requirement that the Secretary adopt security standards that take into account the needs and capabilities of small health care providers and rural health care providers,^[991] the Department considered excepting small and rural health care providers from the requirement to perform penetration testing at proposed 45 CFR 164.308(h)(2)(iii) to lower anticipated costs of the rule for such providers. The Department estimates that approximately 90 percent of providers are small (based on revenue). Thus, the estimated cost reduction from this exemption (as compared to the proposed requirement for all regulated entities), would be approximately $266,389,139 [822,600 × .9 × 3 hours × $119.94 wage of an information security analyst] annually. While the Department is aware of the cost implications of this requirement for small and rural health care providers, we also believe that penetration testing is a critical component of managing vulnerability to cyberthreats across the health care sector. Additionally, we believe that setting different requirements for cybersecurity for small and rural health care providers would lead such health care providers to believe that they can limit their investment in cybersecurity. Given that a significant amount of health care is provided by small and rural health care providers, limiting their investment in cybersecurity would create a sizable gap in security protections. Such a gap has the potential to increase such providers' attractiveness to cybercriminals.

The Department also considered proposing to permit small and rural health care providers to adopt alternate compensating controls, in lieu of the specified implementation specifications, to meet certain standards. After careful consideration, the Department concluded that it potentially could be just as costly to identify and adopt compensating controls that are reasonable and appropriate for small and rural health care practices. Small and rural health care providers would likely need to either hire personnel or contract with cybersecurity experts to identify potential compensating controls that would meet the relevant standard and provide implementation support. Accordingly, the Department declines to put forward such proposals at this time.

The Federal Information Security Modernization Act

The Department considered the requirements of the Federal Information Security Modernization Act (FISMA) ^[992] and whether compliance with FISMA by Federal agencies that are also regulated entities would be comparable to meeting the proposals in this NPRM. FISMA requires each Federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.^[993] After careful consideration, the Department does not believe that a regulated entity's compliance with FISMA would necessarily ensure compliance with all applicable proposed requirements in this NPRM because FISMA's requirements and the Security Rule's requirements are designed to serve different purposes. FISMA primarily focuses on securing Federal information systems, while the Security Rule applies specifically to ePHI. This NPRM contains specific proposed requirements, not found in FISMA, which are tailored to ensure the confidentiality, integrity, and availability of ePHI. Therefore, although the Department believes that FISMA requirements are consistent with those in the Security Rule and the proposals in this NPRM, we decline to propose that compliance with FISMA requirements would be a comparable alternative to compliance with the proposals in this NPRM. Instead, we believe that FISMA requirements complement the Security Rule and the proposed requirements and will facilitate the ability of regulated entities that are also subject to FISMA to fulfill their compliance with the HIPAA Rules.

Modifications to the Definition of “Information System”

The Department considered proposing additional modifications to the definition of “information system.” The Security Rule currently defines the term “information system” as an interconnected set of information resources under the same direct management control that shares common functionality and includes hardware, software, information, data, applications, communications, and people.^[994] This definition is based on the definition of “general support system” or “system” in the appendix to the 1996 version of OMB Circular A-130, Security of Federal Automated Information Systems.^[995] We considered proposing to remove the phrase “under the same direct management control” as a potential way to clarify the application of the definition to cloud-based computing. Cloud computing applications play an important role in health care today. For example, many health care providers have implemented cloud-based electronic health records (EHRs) and practice management systems. These applications are used to create, receive, maintain, and transmit ePHI, and as such, should be included as components of a covered entity's relevant electronic information system, a term which is based upon the term “information system.” After careful consideration, we have decided to retain the phrase “under the same direct ( print page 1006) management control” and instead clarify in the preamble how the definition of “information system” applies in cloud computing environments. The Department also requests comment on the definition of “information system” and the extent of control a regulated entity has with respect to applications in cloud computing environments.

We also considered proposing to adopt the definition of “information system” in the Paperwork Reduction Act of 1995 (PRA) and the current operative version of OMB Circular A-130.^[996] The PRA and OMB Circular A-130 define “information system” as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.” The Department declined to adopt this definition because the existing definition in the Security Rule based on the definition of “system” in the 1996 version of OMB Circular A-130 more accurately reflects the typical components of an information system and the full extent of resources that are addressed by the Security Rule. Additionally, the definition of “information system” in the PRA and current operative version of OMB Circular A-130 contains some terms that are defined by the HIPAA Rules and some that are not. As a result, adopting this definition would require the Department to propose definitions to such additional terms and to ensure that the manner in which the terms with existing definitions are used is consistent with those existing definitions, and we are concerned that such change could cause significant confusion for regulated entities.

We do not believe that either of the alternative definitions considered would have generated a quantifiable change in costs because the alternatives would be clarifications to existing requirements and would not have changed the scope of the Security Rule's applicability.

Exception From Multi-Factor Authentication (MFA) Requirement

The Department considered proposing an exception to the MFA authentication requirement that would permit regulated entities in the future to adopt other technologies, in lieu of MFA, that might offer a more secure method of authenticating user identity.^[997] Based on discussions with cybersecurity experts, the Department believes that MFA is likely to remain the most secure method for authenticating user identity in future years. It may take different forms, but it will still, at its core, meet the definition of MFA proposed in this NPRM for the foreseeable future.^[998]

While the Department acknowledges that technology will continue to evolve, we are unable to predict when and whether future technology will address identity verification and exceed the level of protection offered by MFA. This uncertainty renders us unable to articulate requirements specific enough to justify a purposeful exception. Because of the uncertainty surrounding new technologies, we are also unable to estimate costs of adopting this alternative. Our current view is that proposing and codifying such an exception would be premature, but we will revisit the proposed specific requirement for MFA, if adopted, and reconsider the need for an exception should a more secure technology emerge.

Transition for Business Associates and Group Health Plans

The Department considered requiring regulated entities to comply with all of the proposals in this NPRM by the compliance date, rather than proposing transition provisions for existing business associate agreements or other contractual arrangements. Had the Department taken that approach, we would have proposed that regulated entities update all existing business associate agreements by the proposed compliance date to comply with all applicable proposed requirements in this NPRM. While the Department believes that many of the proposals in this NPRM are consistent with the Security Rule as it currently exists, we are also concerned that too many regulated entities are not currently compliant with the Security Rule. Given the demonstrable increase in breaches, we believe that it is more important for regulated entities to first improve their cybersecurity posture by coming into compliance with all applicable proposed requirements in this NPRM, if adopted. Upon doing so, the Department anticipates that regulated entities will be better positioned to evaluate their contractual needs and to modify existing business associate agreements. For this reason, the Department has proposed the transition provisions in proposed 45 CFR 164.318. Not allowing for a transition period could have an opportunity cost whereby regulated entities spend their limited time revising business associate agreements instead of enhancing their cybersecurity posture. The Department believes that this could result in duplicative costs because some regulated entities may identify the need for additional changes to business associate agreements after they have fully evaluated their changed cybersecurity needs. The Department estimates that small regulated entities may be more likely to experience that outcome without a transition period, and thus the alternative of no transition period would cause a potential one-time increase in costs of $278,332,891 [(1,822,600 regulated entities × .9) × 1 hour × $169.68 lawyer hourly wage].

Relatedly, the Department considered proposing similar transition provisions for group health plans and plan sponsors that would provide these entities with additional time to update plan documents to align with new proposed requirements in this NPRM, if adopted. However, the Department believes that affected plans and plan sponsors would be able to complete any necessary updates by the proposed compliance date. The Department believes that updating plan documents is not as complex a task as evaluating potential new contractual needs to meet business associate obligations. Additionally, plan sponsors do not have Security Rule obligations independent of plan documents, and thus would not be obligated to implement the requirements proposed in this NPRM absent updates to the plan documents. The result of a transition period for updating plan documents would be merely to delay compliance with the changed Security Rule requirements, and therefore, delay improvements to their cybersecurity posture, not to reduce costs. Accordingly, we are not proposing such transition provisions in this NPRM.

C. Regulatory Flexibility Act—Small Entity Analysis

The Department has examined the economic implications of this proposed rule as required by the RFA. If a rule has a significant economic impact on a substantial number of small entities, the RFA requires agencies to analyze regulatory options that would reduce the economic effect of the rule on small entities. As discussed in greater detail below, this analysis concludes, and the Secretary proposes to certify, that the proposed rule, if finalized, would not ( print page 1007) result in a significant economic effect on a substantial number of small entities.

For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The Act defines “small entities” as (1) a proprietary firm meeting the size standards of the SBA, (2) a nonprofit organization that is not dominant in its field, and (3) a small government jurisdiction of less than 50,000 population. The Department has determined that roughly 90 percent or more of all health care providers meet the SBA size standard for a small business as shown in table 4 or are a nonprofit organization. Therefore, the Department estimates that there would be 740,348 small entities affected by the proposals in this proposed rule.^[999] The SBA size standard for health care providers ranges between a maximum of $9 million and $47 million in annual receipts, depending upon the type of entity, as shown in table 4, above.^[1000]

With respect to health insurers, the SBA size standard is a maximum of $47 million in annual receipts, and for pharmacy benefits and clearinghouses it is $45.5 million.^[1001] While some insurers are classified as nonprofit, it is possible they are dominant in their market. For example, a number of Blue Cross/Blue Shield insurers are organized as nonprofit entities; and yet, they dominate the health insurance market in the States where they are licensed.^[1002]

With respect to business associates, they provide a wide range of services for covered entities, including computer infrastructure, clearinghouse activities, leased office equipment, and professional services, such as legal, accounting, business planning, and marketing. The SBA size thresholds for these industries ranges from $15.5 million for lawyers to $47 million for clearinghouses.^[1003]

For the reasons stated below, the Department does not expect that the cost of compliance would be significant for small entities. Nor does the Department expect that the cost of compliance would fall disproportionately on small entities. Although many of the regulated entities affected by the proposals in this proposed rule are small entities, they would not bear a disproportionate cost burden compared to the other entities subject to the rule. The projected total costs are discussed in detail in the RIA. The Department does not view this as a substantial burden because the result of the changes would be annualized costs per regulated entity of approximately $1,235 [= $2.3 billion ^[1004] /1,822,600 regulated entities]. The per-entity costs represent the costs per establishment. As a result, smaller entities' costs are lower because they have fewer establishments. Larger regulated entities ( i.e., firms) that have multiple facilities ( i.e., establishments) would experience higher costs than the average cost per establishment because each firm would need to apply the proposals to all of their establishments. In the context of the RFA, HHS generally considers an economic impact exceeding 3 percent of annual revenue to be significant, and 5 percent or more of the affected small entities within an identified industry to represent a substantial number.

More than 5 percent of the small covered entities listed under the NAICS codes in table 4 are one-establishment firms with fewer than five employees,^[1005] so the analysis must determine how the effects of the quantified costs on one-establishment firms compare to their revenues. As explained above, the cost for a one-establishment firm is $1,235, so only small firms whose revenues are below $41,167 [=$1,235/0.03] would experience an effect exceeding 3 percent.

Among the NAICS codes for health care providers, the small firms with the lowest revenues are one-establishment HMO [Health Maintenance Organization] Medical Centers (NAICS 621491) with fewer than five employees, which had an estimated average yearly revenue in 2021 of $108,000. Residential Intellectual and Developmental Disability Facilities (NAICS 623210) had the second lowest revenues for one-establishment firms with fewer than five employees, with $180,000. Offices of Mental Health Practitioners (NAICS 621330) have the third lowest revenues for one-establishment firms with fewer than five employees, with $189,000. Thus, the Department believes that almost all regulated entities have annual revenues that exceed these amounts.

The Department acknowledges that there may be very small firms—namely firms without employees—whose revenues are below $41,167. We believe that such firms would comply with the regulation by purchasing services from software and web-hosting companies whose costs may increase as a result of the proposed changes. Such software and web-hosting companies would be business associates, and thus costs to them are already accounted for. We believe that, to the extent that these business associates decide to recover their minor cost increases by raising the prices of the services sold to non-employer firms, these incremental costs passed through to their small-firm customers would be negligible because they will be spread among many non-employer firms.

The Department has separately analyzed the effects of the NPRM on health plan sponsors and does not view the projected costs as a significant burden because the proposed changes would result in annualized costs per plan sponsor of approximately $6,133 [=$4,552,995,816/742,411 health plan sponsors]. The quantified impact of $6,133 per health plan sponsor would only apply to those sponsors whose annual revenue is $204,433 or less.^[1006] The Department believes there are few, if any, group health plan sponsors with annual revenues below this amount because the average revenue of a U.S. business with 1-4 employees is $387,000 ^[1007] and employers with 0-1 employees are unlikely to sponsor a group health plan.

Accordingly, the Department believes that this proposed rule, if adopted, would be unlikely to affect a substantial ( print page 1008) number of small entities that meet the RFA threshold. Thus, this analysis concludes, and the Secretary proposes to certify, that the NPRM would not result in a significant economic effect on a substantial number of small entities.

HIPAA requires the Department to consider the needs and capabilities of small and rural health care providers.^[1008] As we explained in our 2003 analysis of the effect of the Security Rule on small and rural health care providers, the scalability provisions preclude the need to precisely define those categories.^[1009] We have long considered the effect of our rules on small businesses in the Small Entity Analysis discussed above. However, because of the breadth of changes proposed in this NPRM, the Department has considered more closely how it would affect rural health care providers. There are approximately 2,000 rural hospitals,^[1010] comprising nearly 30 percent of all hospitals [= 2,057/7,465],^[1011] and the Department estimates approximately 7 to 8 percent of all health care providers operate in rural areas (counties or micropolitan areas with fewer than 50,000 inhabitants). See Regulated Entities Affected in Section V.A.2. Baseline Conditions, above.

Because rural health care providers are more likely to be small businesses, they would be affected in a manner similar to small entities, as demonstrated in the Small Entity Analysis above. Likewise, to the extent that Tribal health care providers are in rural areas, which many are,^[1012] our analysis of the effects on rural health care providers generally also applies. However, Tribal health providers have the benefit of access to centralized supportive services for health IT and EHR adoption, which other rural providers may lack.^[1013] A primary barrier to both adoption of health information technology (health IT) and deployment of cybersecurity safeguards in rural communities is limited access to high-speed internet. Rural health care providers, such as hospitals, have adopted EHRs at a lower rate than non-rural hospitals,^[1014] and thus may also have fewer electronic information systems that are subject to the Security Rule requirements, which could ease some burdens of compliance. However, as EHR adoption has increased in rural hospitals,^[1015] so too have the risks of cybersecurity attacks.^[1016] Rural health care providers are more likely to have limited resources to update legacy information technology (IT) systems, implement new or changed regulatory requirements, and respond to large breaches. Additionally, the health IT workforce is more limited in rural areas, which may affect the ability of rural health care providers to access in-person technical assistance. Because most rural hospitals are “located more than 35 miles from another hospital,” responding to cyberattacks may be more challenging.^[1017] We request comment on the burdens these proposals would impose on rural health care providers, including rural hospitals.

Rural health care providers and other regulated entities can avail themselves of grants and incentives to improve broadband access and adoption of health IT.^[1018] For cybersecurity in particular, the White House, in partnership with private companies, announced the availability of direct assistance to rural health care providers on cybersecurity in the form of grants, discounts, and technical advice.^[1019] Additionally, CISA has compiled a list of free services and tools available to regulated entities from private and public sector entities. CISA also has published, in partnership with the Joint Cyber Defense Collaborative, a list of cybersecurity resources especially focused on high-risk communities.^[1020] And the Advanced Research Projects Agency for Health announced plans to invest $50 million to develop an autonomous solution for addressing cyberthreats to assist hospitals in defending their information systems.^[1021]

Cybersecurity is as essential for small and rural health care providers and their business associates, as it is for large and urban regulated entities. The seamless flow of data and increased connectivity means that threats to one health care provider do not affect only that one health care provider, regardless of size or location. The effects on patient care may be greater in rural environments where fewer alternatives exist if care is delayed or denied as a result of a cyberattack or malfunction.^[1022] As discussed in the preamble, the factors described at 45 CFR 164.306(b)(2) provide the flexibility for small and rural providers, in particular, to adopt security measures that are reasonable and appropriate for their circumstances.

D. Executive Order 13132—Federalism

As required by E.O. 13132 on Federalism,^[1023] the Department has examined the provisions in the proposed regulation for their effects on the relationship between the Federal Government and the States. E.O. 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has federalism implications. In the Department's view, the proposed rule would not have any federalism implications.

The federalism implications of the Security Rule were also assessed as required by E.O. 13132 and published as part of the preambles to the final rules on February 20, 2003 ^[1024] and January ( print page 1009) 25, 2013.^[1025] Regarding preemption, HIPAA dictates the relationship between State law and HIPAA regulatory requirements.^[1026] The Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act) provides that the HIPAA preemption provisions shall apply to the HITECH Act provisions and requirements.^[1027] As explained by the House report that accompanied the American Recovery and Reinvestment Act of 2009, the HITECH Act would not only apply HIPAA's preemption provisions to the HITECH Act requirements, but it would also “preserve the HIPAA privacy and security standards to the extent that they are consistent with” the HITECH Act.^[1028]

A requirement, standard, or implementation specification adopted in accordance with HIPAA and the HIPAA Rules supersedes any contrary provision of State law, subject to certain exceptions.^[1029] Specifically, State law would be preempted under the Security Rule only when (1) a regulated entity finds it impossible to comply with both State and Federal requirements; or (2) the provision of State law stands as an obstacle to accomplishing and executing the purposes and objectives of the Administrative Simplification provisions or the HITECH Act.^[1030] Although a few States ( e.g., California and New York) have promulgated or are in the process of promulgating regulations pertaining to cybersecurity in health care that may be more stringent than the Security Rule, the Department believes that a regulated entity could comply with both sets of requirements by adhering to the more stringent standard. Thus, in such cases, the State law would not be an obstacle to the accomplishment and execution of HIPAA or the HITECH Act.

The proposed modifications to the Security Rule would further the Congressional intent to improve the Medicare and Medicaid programs by the development of health information systems that are private and secure. The Department's proposals promote the safety, efficiency, and effectiveness of the health care system by refining the security standards established by Congress and implemented in the 2003 and 2013 Final Rules. The statute contemplated that the security measures adopted by all regulated entities, including State and local governments, would evolve over time in accordance with the security risks they face, and the NPRM proposals are in the nature of enhancing these existing requirements. Thus, the Department does not believe that the rule would impose substantial direct compliance costs on State and local governments that are not required by statute.

The Department anticipates that the most significant direct costs on State and local governments would be for conducting a Security Rule compliance audit; notifying covered entities or business associates, as applicable, upon activation of a contingency plan; notifying covered entities of changes or termination of workforce members' access to ePHI; deploying MFA; removing extraneous software; and penetration testing; providing or obtaining verification of business associates' compliance with technical safeguards; updating health plan documents; updating policies and procedures; and updating workforce training. However, the costs involved can be attributed to the statutory requirements of the Administrative Simplification provisions of HIPAA and would be similar in kind to those borne by non-government-operated regulated entities, which the proposed RIA above addresses in detail.

In considering the principles in and requirements of E.O. 13132, the Department believes that these proposed modifications to the Security Rule would not significantly affect the rights, roles, and responsibilities of the States and requests comment on this analysis.

E. Assessment of Federal Regulation and Policies on Families

Section 654 of the Treasury and General Government Appropriations Act of 1999 ^[1031] requires Federal departments and agencies to determine whether a proposed policy or regulation could affect family well-being. If the determination is affirmative, then the Department or agency must prepare an impact assessment to address criteria specified in the law. This proposed rule is expected to strengthen family well-being because it would ensure a baseline of security measures for individuals' PHI, and medical information and decisions based on that information are at the heart of family decision making. If finalized, the provisions in this proposed rule may be carried out only by the Federal Government because it would modify Federal law on cybersecurity in health care, ensuring that American families have confidence that the privacy of their PHI is secured by consistent safeguards, regardless of the State where they are located when health care is provided. Such health care privacy and is vital for individuals who seek or access health care.

F. Paperwork Reduction Act of 1995

Under the PRA,^[1032] agencies are required to submit to OMB for review and approval any reporting or recordkeeping requirements inherent in a proposed or final rule and are required to publish such proposed requirements for public comment. To fairly evaluate whether an information collection should be approved by the OMB, section 3506(c)(2)(A) of the PRA requires that the Department solicit comment on the following issues:

1. Whether the information collection is necessary and useful to carry out the proper functions of the agency.

2. The accuracy of the agency's estimate of the information collection burden.

3. The quality, utility, and clarity of the information to be collected.

4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

The PRA requires consideration of the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section. The Department solicits public comments on its assumptions and burden estimates in this NPRM as summarized below.

In this RIA, the Department proposes to revise certain information collection requirements associated with this NPRM and, as such, would revise the information collection last prepared in 2024 and approved under OMB control #0945-0003.^[1033] The proposed revisions to the information collection describe all new and adjusted information ( print page 1010) collection requirements for regulated entities pursuant to the implementing regulation for HIPAA at 45 CFR parts 160 and 164, the HIPAA Privacy, Security, Breach Notification, and Enforcement Rules (“HIPAA Rules”).

The estimated annual labor burden presented by the regulatory modifications is 77,067,552 burden hours at a first-year cost of $9,314,106,174. These figures, respectively, represent the sum of 37,781,637 new burden hours at a cost of $4,655,324,954 for compliance by regulated entities and 39,285,915 new burden hours at a cost of $4,658,781,219 for compliance by health plan sponsors.

The overall total burden for respondents to comply with the information collection requirements of all of the HIPAA Privacy, Security, and Breach Notification Rules, including new burdens presented by proposed program changes, is estimated to be 925,144,023 burden hours at a cost of $109,085,104,674, plus $163,499,411 in capital costs for a total estimated annual burden of $109,248,604,085, after the effective date of the final rule. This estimate is based on a total of 1,202,562,864 responses for a total of 2,565,011 respondents. The total burden for the HIPAA Rules, including the changes proposed in this NPRM, would result in a decrease of 28,838,213 burden hours and a cost increase of $1,911,898,144, in comparison to the baseline in the ICR associated with the 2024 Privacy Rule to Support Reproductive Health Care Privacy.^[1034] This is the result of multiples changes, such as decreasing burden hours for some existing requirements, increasing the estimated number of covered entities, adding new Security Rule requirements, and expanding the pool of respondents for the Security Rule by adding requirements for health plan sponsors.

Details describing the burden analysis for the proposals associated with this RIA are presented below and explained further in the ICR associated with the NPRM.

1. Explanation of Estimated Annualized Burden Hours

Below is a summary of the significant program changes and adjustments proposed since the approved 2024 ICR; because the ICR addresses regulatory burdens associated with the full suite of HIPAA Rules, the changes and adjustments include updated data and estimates for some provisions of the HIPAA Rules that are not affected by this proposed rule. These program changes and adjustments form the bases for the burden estimates presented in the ICR associated with this NPRM.

Adjusted Estimated Annual Burdens of Compliance

(1) Updating the number of covered entities.

(2) Updating hourly wage rates.

(3) Adjusting downward the number of estimated requests for an exception to Federal preemption of State law to the prior baseline of 1 request per year.

(4) Adjusting downward the estimated hourly burden for regulated entities to report security incidents (not breaches) from 20 hours per monthly report to 10 hours per monthly report.

(5) Updating the number of research disclosures.

New Burdens Resulting From Program Changes

In addition to the adjustments above, the Department proposes to add new annual estimated burdens as a result of program changes, as follows:

(1) A burden of 2 hours for each regulated entity to conduct a Security Rule compliance audit.

(2) A burden of 2 hours for each business associate (including each subcontractor) to provide verification of compliance with technical safeguards.

(3) A burden of .5 hours for each covered entity to obtain verification of business associates' compliance with technical safeguards.

(4) A burden of .083 hours for each business associate to obtain verification of subcontractors' compliance with technical safeguards.

(5) A burden of 1 hour for each regulated entity to provide notification to other regulated entities of workforce members' termination of access to ePHI.

(6) A burden of 1.5 hours for each regulated entity to deploy MFA.

(7) A burden of 4.5 hours for each regulated entity to perform network segmentation.

(8) A burden of .5 hours for approximately 76.56 percent of regulated entities to disable unused ports and remove extraneous software.

(9) A burden of 3 hours for each regulated entity to conduct penetration testing.

(10) A burden of .5 hours for each regulated entity to notify covered entities or business associates, as applicable, upon activation of a contingency plan.

(11) A burden of .5 hours for each insurer and third-party administrator to update health plan documents.

(12) A burden of 2 hours for each regulated entity to update the content of its cybersecurity awareness and Security Rule training program.

(13) A burden of 3.5 hours for each regulated entity to update its policies and procedures.

(14) A burden of 1 hour for each regulated entity to update business associate agreements.

(15) A burden of 52.92 hours for each health plan sponsor to modify safeguards for its relevant electronic information systems to meet Security Rule standards.

List of Subjects

45 CFR Part 160

• Administrative practice and procedure
• Computer technology
• Electronic information system
• Electronic transactions
• Employer benefit plan
• Group health plan
• Health
• Health care
• Health facilities
• Health insurance
• Health professions
• Health records
• Hospitals
• Investigations
• Medicaid
• Medical Research
• Medicare
• Penalties
• Preemption
• Privacy
• Public health
• Reporting and recordkeeping requirements
• Security

45 CFR Part 164

• Administrative practice and procedure
• Computer technology
• Drug abuse
• Electronic information system
• Electronic transactions
• Employer benefit plan
• Group health plan
• Health
• Health care
• Health facilities
• Health insurance
• Health professions
• Health records
• Hospitals
• Medicaid
• Medical research
• Medicare
• Privacy
• Public health
• Reporting and recordkeeping requirements
• Security

Proposed Rule

For the reasons stated in the preamble, the Department of Health and Human Services proposes to amend 45 CFR subtitle A, subchapter C, parts 160 and 164 as set forth below:

PART 160—GENERAL ADMINISTRATIVE REQUIREMENTS

1. The authority citation for part 160 continues to read as follows:

Authority: 42 U.S.C. 1302(a); 42 U.S.C. 1320d-1320d-9; sec. 264, Pub. L. 104-191, 110 Stat. 2033-2034 (42 U.S.C. 1320d-2 (note)); 5 U.S.C. 552; secs. 13400-13424, Pub. L. 111-5, 123 Stat. 258-279; and sec. 1104 of Pub. L. 111-148, 124 Stat. 146-154.

2. Amend § 160.103 by revising the definition of “Electronic media” to read as follows:

§ 160.103

Definitions.

* * * * *

Electronic media means:

(1) Electronic storage material on which data may be recorded, maintained, or processed. This includes, but is not limited to, hard drives, ( print page 1011) removable media, magnetic tape, optical disk, and any other form of digital memory or storage.

(2) Transmission media used to exchange information already in electronic storage material. Transmission media includes, but is not limited to, the internet, extranet or intranet, leased lines, dial-up lines, private and public networks, and the physical movement of removable/transportable electronic storage material.

* * * * *

PART 164—SECURITY AND PRIVACY

1. The authority citation for part 164 continues to read as follows:

Authority: 42 U.S.C. 1302(a); 42 U.S.C. 1320d-1320d-9; sec. 264, Pub. L. 104-191, 110 Stat. 2033-2034 (42 U.S.C. 1320d-2(note)); and secs. 13400-13424, Pub. L. 111-5, 123 Stat. 258-279.

2. Revise and republish subpart C to read as follows:

Subpart C—Security Standards for the Protection of Electronic Protected Health Information

164.302

Applicability.

164.304

Definitions.

164.306

Security standards: General rules.

164.308

Administrative safeguards.

164.310

Physical safeguards.

164.312

Technical safeguards.

164.314

Organizational requirements.

164.316

Documentation requirements.

164.318

Transition provisions.

164.320

Severability.

Appendix A to Subpart C of Part 164—Security Standards: Matrix

Authority: 42 U.S.C. 1320d-2 and 1320d-4; 42 U.S.C. 17931.

§ 164.302

Applicability.

A covered entity or business associate must comply with the applicable standards, implementation specifications, and requirements of this subpart with respect to electronic protected health information of a covered entity.

§ 164.304

Definitions.

As used in this subpart, the following terms have the following meanings:

Access means the ability or the means necessary to read, write, modify, delete, transmit, or communicate data/information or otherwise use any component of an information system. (This definition applies to “access” as used in this subpart, not as used in subpart D or E of this part.)

Administrative safeguards are administrative actions and related policies and procedures to manage the selection, development, implementation, and maintenance (including updating and modifying) of security measures to protect electronic protected health information, and to manage the conduct of the covered entity's or business associate's workforce in relation to the protection of that information.

Authentication means the corroboration that a person or technology asset is the one they are claiming to be.

Availability means the property that data or information is accessible and useable upon demand by an authorized person or technology asset.

Confidentiality means the property that data or information is not made available or disclosed to unauthorized persons, technology assets, or processes.

Deploy means to configure technology for use and implement such technology.

Electronic information system means interconnected set of electronic information resources under the same direct management control that shares common functionality. An electronic information system generally includes technology assets, such as hardware, software, electronic media, information, and data.

Encryption means the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key.

Facility means the physical premises and the interior and exterior of a building(s).

Implement means to put into effect and be in use, operational, and function as expected throughout the covered entity or business associate.

Information system means an interconnected set of information resources under the same direct management control that shares common functionality. An information system generally includes hardware, software, information, data, communications, and people.

Integrity means the property that data or information have not been altered or destroyed in an unauthorized manner.

Malicious software means software or firmware intended to perform an unauthorized action or activity that will have adverse impact on an electronic information system and/or the confidentiality, integrity, or availability of electronic protected health information. Examples include but are not limited to viruses, worms, Trojan horses, spyware, and some forms of adware.

Multi-factor authentication means authentication of the user's identity through verification of at least two of the following three categories:

(1) Information known by the user, including but not limited to a password or personal identification number (PIN).

(2) Item possessed by the user, including but not limited to a token or a smart identification card.

(3) Personal characteristic of the user, including but not limited to fingerprint, facial recognition, gait, typing cadence, or other biometric or behavioral characteristics.

Password means confidential authentication information composed of a string of characters, such as letters, numbers, spaces, and other symbols.

Physical safeguards are physical measures and related policies and procedures to protect a covered entity's or business associate's relevant electronic information systems, and related facilities and equipment, from natural and environmental hazards and unauthorized intrusion.

Relevant electronic information system means an electronic information system that creates, receives, maintains, or transmits electronic protected health information or that otherwise affects the confidentiality, integrity, or availability of electronic protected health information.

Risk means the extent to which the confidentiality, integrity, or availability of electronic protected health information is threatened by a potential circumstance or event.

Security or security measures encompass all of the administrative, physical, and technical safeguards in or applied to an information system.

Security incident means any of the following:

(1) The attempted or successful unauthorized access, use, disclosure, modification, or destruction of information in an information system.

(2) The attempted or successful unauthorized interference with system operations in an information system.

Technical controls means the technical mechanisms contained in the hardware, software, or firmware components of an electronic information system that are primarily implemented and executed by the electronic information system to protect the information system and data therein.

Technical safeguards means the technology, technical controls, and related policies and procedures governing the use of the technology that protects and controls access to electronic protected health information.

Technology asset means the components of an electronic information system, including but not ( print page 1012) limited to hardware, software, electronic media, information, and data.

Threat means any circumstance or event with the potential to adversely affect the confidentiality, integrity, or availability of electronic protected health information.

User means a person with authorized access.

Vulnerability means a flaw or weakness in an information system, information system security procedures, design, implementation, or technical controls that could be intentionally exploited or accidentally triggered by a threat.

Workstation means an electronic computing device and electronic media stored in its immediate environment. Workstation includes but is not limited to the following types of devices: a server, desktop computer, laptop computer, virtual device, and mobile device such as a smart phone or tablet.

§ 164.306

Security standards: General rules.

(a) General requirements. Each covered entity and business associate must do the following with respect to all electronic protected health information it creates, receives, maintains, or transmits:

(1) Ensure the confidentiality, integrity, and availability of the electronic protected health information.

(2) Protect against any reasonably anticipated threats or hazards to the confidentiality, integrity, or availability of the electronic protected health information.

(3) Protect against any reasonably anticipated uses or disclosures of the electronic protected health information that are not permitted or required under subpart E of this part.

(4) Ensure compliance by its workforce with this subpart and all administrative, physical, and technical safeguards implemented in accordance with this subpart.

(b) Flexibility of approach. (1) Covered entities and business associates may use any reasonable and appropriate security measures that allow the covered entity or business associate to implement the standards and implementation specifications as specified in this subpart.

(2) In deciding which security measures to use, a covered entity or business associate must take into account all of the following factors:

(i) The size, complexity, and capabilities of the covered entity or business associate.

(ii) The covered entity's or the business associate's technical infrastructure, hardware, and software security capabilities.

(iii) The costs of security measures.

(iv) The probability and criticality of potential risks to electronic protected health information.

(v) The effectiveness of the security measure in supporting the resiliency of the covered entity or business associate.

(c) Standards and implementation specifications. A covered entity or business associate must comply with the applicable standards, including their implementation specifications, as provided in this subpart.

§ 164.308

Administrative safeguards.

(a) A covered entity or business associate must, in accordance with §§ 164.306 and 164.316, implement all of the following administrative safeguards to protect the confidentiality, integrity, and availability of all electronic protected health information that it creates, receives, maintains, or transmits:

(1) Standard: Technology asset inventory —(i) General. Conduct and maintain an accurate and thorough written inventory and a network map of the covered entity's or business associate's electronic information systems and all technology assets that may affect the confidentiality, integrity, or availability of electronic protected health information.

(ii) Implementation specifications —(A) Inventory. Develop a written inventory of the covered entity's or business associate's technology assets that contains the identification, version, person accountable, and location of each technology asset.

(B) Network map. Develop a network map that illustrates the movement of electronic protected health information throughout the covered entity's or business associate's electronic information systems, including but not limited to how electronic protected health information enters and exits such information systems, and is accessed from outside of such information systems.

(C) Maintenance. Review and update the written inventory of technology assets required by paragraph (a)(1)(ii)(A) of this section and the network map required by paragraph (a)(1)(ii)(B) of this section in the following circumstances:

( 1) On an ongoing basis, but at least once every 12 months.

( 2) When there is a change in the covered entity's or business associate's environment or operations that may affect electronic protected health information, including but not limited to the adoption of new technology assets; the upgrading, updating, or patching of technology assets; newly recognized threats to the confidentiality, integrity, or availability of electronic protected health information; a sale, transfer, merger, or consolidation of all or part of the covered entity or business associate with another person; a security incident that affects the confidentiality, integrity, and availability of electronic protected health information; and relevant changes in Federal, State, Tribal, or territorial law.

(2) Standard: Risk analysis —(i) General. Conduct an accurate and comprehensive written assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information created, received, maintained, or transmitted by the covered entity or business associate.

(ii) Implementation specifications —(A) Assessment. The written assessment must include, at a minimum, all of the following:

( 1) A review of the technology asset inventory required by paragraph (a)(1)(ii)(A) of this section and the network map required by paragraph (a)(1)(ii)(B) of this section to identify where electronic protected health information may be created, received, maintained, or transmitted within the covered entity's or business associate's electronic information systems.

( 2) Identification of all reasonably anticipated threats to the confidentiality, integrity, and availability of electronic protected health information that the covered entity or business associate creates, receives, maintains, or transmits.

( 3) Identification of potential vulnerabilities and predisposing conditions to the covered entity's or business associate's relevant electronic information systems.

( 4) An assessment and documentation of the security measures the covered entity or business associate uses to ensure the confidentiality, integrity, and availability of the electronic protected health information created, received, maintained, or transmitted by the covered entity or business associate.

( 5) A reasonable determination of the likelihood that each threat identified in accordance with paragraph (a)(2)(ii)(A)( 2) of this section will exploit the vulnerabilities identified in accordance with paragraph (a)(2)(ii)(A)( 3) of this section.

( 6) A reasonable determination of the potential impact of each threat identified in accordance with paragraph (a)(2)(ii)(A)( 2) of this section successfully exploiting the vulnerabilities identified in accordance with paragraph (a)(2)(ii)(A)( 3) of this section. ( print page 1013)

( 7) An assessment of risk level for each threat identified in accordance with paragraph (a)(2)(ii)(A)( 2) of this section and vulnerability identified in accordance with paragraph (a)(2)(ii)(A)( 3) of this section, based on the determinations made in accordance with paragraphs (a)(2)(ii)(A)( 5) and ( 6) of this section.

( 8) An assessment of the risks to electronic protected health information posed by entering into or continuing a business associate contract or other written arrangement with any prospective or current business associate, respectively, based on the written verification obtained from the prospective or current business associate in accordance with paragraph (b)(1) of this section.

(B) Maintenance. Review, verify, and update the written assessment on an ongoing basis, but at least once every 12 months and, in accordance with paragraph (a)(1)(ii)(C)( 2) of this section, in response to a change in the covered entity's or business associate's environment or operations that may affect electronic protected health information.

(3) Standard: Evaluation —(i) General. Perform a written technical and nontechnical evaluation to determine whether a change in the covered entity's or business associate's environment or operations may affect the confidentiality, integrity, or availability of electronic protected health information.

(ii) Implementation specifications —(A) Performance. Perform a written technical and nontechnical evaluation within a reasonable period of time before making a change in the covered entity's or business associate's environment or operations as described in paragraph (a)(1)(ii)(C)( 2) of this section.

(B) Response. Respond to the written technical and nontechnical evaluation in accordance with the covered entity's or business associate's risk management plan required by paragraph (a)(5)(ii)(A) of this section.

(4) Standard: Patch management —(i) General. Implement written policies and procedures for applying patches and updating the configuration(s) of the covered entity's or business associate's relevant electronic information systems.

(ii) Implementation specifications —(A) Policies and procedures. Establish written policies and procedures for identifying, prioritizing, acquiring, installing, evaluating, and verifying the timely installation of patches, updates, and upgrades throughout the covered entity's or business associate's relevant electronic information systems.

(B) Maintenance. Review and test written policies and procedures required by paragraph (a)(4)(ii)(A) of this section at least once every 12 months, and modify such policies and procedures as reasonable and appropriate.

(C) Application. Patch, update, and upgrade the configurations of relevant electronic information systems in accordance with the written policies and procedures required by paragraph (a)(4)(ii)(A) of this section and based on the results of the covered entity's or business associate's risk analysis required by paragraph (a)(2) of this section, the vulnerability scans required by § 164.312(h)(2)(i), the monitoring of authoritative sources required by § 164.312(h)(2)(ii), and penetration tests required by § 164.312(h)(2)(iii), within a reasonable and appropriate period of time, as follows, except to the extent that an exception at paragraph (a)(4)(ii)(D) of this section applies:

( 1) Within 15 calendar days of identifying the need to patch, update, or upgrade the configuration of a relevant electronic information system to address a critical risk in accordance with this paragraph (a)(4)(ii)(C), where a patch, update, or upgrade is available; or, where a patch, update, or upgrade is not available, within 15 calendar days of a patch, update, or upgrade becoming available.

( 2) Within 30 calendar days of identifying the need to patch, update, or upgrade the configuration of a relevant electronic information system to address a high risk in accordance with this paragraph (a)(4)(ii)(C), where a patch, update, or upgrade is available; or, where a patch, update, or upgrade is not available, within 30 calendar days of a patch, update, or upgrade becoming available.

( 3) As determined by and documented in the covered entity's or business associate's policies and procedures under paragraph (a)(4)(ii)(A) of this section for all other patches, updates, and upgrades to the configuration of a relevant electronic information system.

(D) Exceptions. This paragraph (a)(4)(ii)(D) applies only to the extent that a covered entity or business associate documents that an exception in this paragraph (a)(4)(ii)(D) applies and that all other applicable conditions are met.

( 1) A patch, update, or upgrade to the configuration of a relevant electronic information system is not available to address a risk identified in the risk analysis under paragraph (a)(2) of this section.

( 2) The only available patch, update, or upgrade would adversely affect the confidentiality, integrity, or availability of electronic protected health information.

(E) Alternative measures. Where an exception at paragraph (a)(4)(ii)(D) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls in accordance with paragraph (a)(4)(ii)(F) of this section.

(F) Compensating controls. To the extent that a covered entity or business associate determines that an exception at paragraph (a)(4)(ii)(D) of this section applies, a covered entity or business associate must implement reasonable and appropriate security measures to address the identified risk in a timely manner as required by paragraph (a)(5)(ii)(D) of this section until a patch, update, or upgrade that does not adversely affect the confidentiality, integrity, or availability of electronic protected health information becomes available.

(5) Standard: Risk management —(i) General. Implement security measures sufficient to reduce risks and vulnerabilities to all electronic protected health information to a reasonable and appropriate level.

(ii) Implementation specifications —(A) Planning. Establish and implement a written risk management plan for reducing risks to all electronic protected health information, including but not limited to those risks identified by the risk analysis under paragraph (a)(2)(ii)(A) of this section, to a reasonable and appropriate level.

(B) Maintenance. Review the written risk management plan required by paragraph (a)(5)(ii)(A) of this section at least once every 12 months and as reasonable and appropriate in response to changes in the risk analysis made in accordance with paragraph (a)(2)(ii)(B) of this section, and modify as reasonable and appropriate.

(C) Priorities. The written risk management plan must prioritize the risks identified in the risk analysis required by paragraph (a)(2)(ii)(A) of this section, based on the risk levels determined by such risk analysis.

(D) Implementation. Implement security measures in a timely manner to address the risks identified in the covered entity's or business associate's risk analysis in accordance with the priorities established under paragraph (a)(5)(ii)(C) of this section.

(6) Standard: Sanction policy —(i) General. Apply appropriate sanctions against workforce members who fail to comply with the security policies and ( print page 1014) procedures of the covered entity or business associate.

(ii) Implementation specifications —(A) Policies and procedures. Establish written policies and procedures for sanctioning workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.

(B) Modifications. Review written sanctions policies and procedures at least once every 12 months, and modify as reasonable and appropriate.

(C) Application. Apply and document appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate in accordance with the written policies and procedures for sanctioning workforce members required by paragraph (a)(6)(ii)(A) of this section.

(7) Standard: Information system activity review —(i) General. Implement written policies and procedures for regularly reviewing records of activity in the covered entity's or business associate's relevant electronic information systems.

(ii) Implementation specifications —(A) Policies and procedures. Establish written policies and procedures for retaining and reviewing records of activity in the covered entity's or business associate's relevant electronic information systems by persons and technology assets, including the frequency for reviewing such records.

(B) Scope. Records of activity in the covered entity's or business associate's relevant electronic information systems by persons and/or technology assets include but are not limited to audit trails, event logs, firewall logs, system logs, data backup logs, access reports, anti-malware logs, and security incident tracking reports.

(C) Record review. Review records of activity in a covered entity's or business associate's relevant electronic information systems by persons and technology assets as often as reasonable and appropriate for the type of report or log and document such review.

(D) Record retention. Retain records of activity in the covered entity's or business associate's relevant electronic information systems by persons and technology assets for a period of time that is reasonable and appropriate for the type of report or log.

(E) Response. Where a suspected or known security incident is identified during the review required by paragraph (a)(7)(ii)(C) of this section, respond in accordance with the covered entity's or business associate's security incident response plan required by paragraph (a)(12)(ii)(A)( 1) of this section.

(F) Maintenance. Review and test the written policies and procedures required by paragraph (a)(7)(ii)(A) of this section at least once every 12 months and modify as reasonable and appropriate.

(8) Standard: Assigned security responsibility. In writing, identify the security official who is responsible for the development and implementation of the policies and procedures, written or otherwise, and deployment of technical controls required by this subpart for the covered entity or business associate.

(9) Standard: Workforce security —(i) General. Implement written policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information and relevant electronic information systems, and to prevent those workforce members who are not authorized to have access from obtaining access to electronic protected health information and relevant electronic information systems.

(ii) Implementation specifications —(A) Authorization and/or supervision. Establish and implement written procedures for the authorization and/or supervision of workforce members who access electronic protected health information or relevant electronic information systems, or who work in facilities where electronic protected health information or relevant electronic information systems might be accessed.

(B) Workforce clearance procedure. Establish and implement written procedures to determine that the access of a workforce member to electronic protected health information or relevant electronic information systems is appropriate in accordance with paragraph (a)(10)(ii)(B) of this section.

(C) Modification and termination procedures. ( 1) Establish and implement written procedures, in accordance with paragraph (a)(9)(ii)(C)( 2) of this section, to terminate a workforce member's access to electronic protected health information and relevant electronic information systems, and to facilities where electronic protected health information or relevant electronic information systems might be accessed.

( 2) A workforce member's access must be terminated as soon as possible but no later than one hour after the employment of, or other arrangement with, a workforce member ends.

(D) Notification. ( 1) Establish and implement written procedures, in accordance with paragraph (a)(9)(ii)(D)( 2) of this section, to notify another covered entity or business associate of a change in or termination of access where the workforce member is or was authorized to access such electronic protected health information or relevant electronic information systems by the covered entity or business associate making the notification.

( 2) Notification must occur as soon as possible but no later than 24 hours after a change in or termination of a workforce member's authorization to access electronic protected health information or relevant electronic information systems maintained by such other covered entity or business associate.

(E) Maintenance. Review and test written policies and procedures required under paragraph (a)(9)(ii)(A) through (D) of this section at least once every 12 months, and modify as reasonable and appropriate.

(10) Standard: Information access management —(i) General. Establish and implement written policies and procedures for authorizing access to electronic protected health information and relevant electronic information systems that are consistent with the applicable requirements of subpart E of this part.

(ii) Implementation specifications —(A) Isolating health care clearinghouse functions. If a health care clearinghouse is part of a larger organization, the clearinghouse must establish and implement written policies and procedures that protect the electronic protected health information and relevant electronic information systems of the clearinghouse from unauthorized access by the larger organization.

(B) Access authorization. Establish and implement written policies and procedures for granting and revising access to electronic protected health information and relevant electronic information systems as necessary and appropriate for each prospective user and technology asset to carry out their assigned function(s).

(C) Authentication management. Establish and implement written policies and procedures for verifying the identities of users and technology assets prior to accessing the covered entity's or business associate's relevant electronic information systems, including written policies and procedures for implementing multi-factor authentication technical controls required by § 164.312(f)(2)(ii) through (v).

(D) Access determination and modification. Establish and implement written policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, determine, document, review, and modify the access of each user and technology asset to specific components ( print page 1015) of the covered entity's or business associate's relevant electronic information systems.

(E) Network segmentation. Establish and implement written policies and procedures that ensure that a covered entity's or business associate's relevant electronic information systems are segmented to limit access to electronic protected health information to authorized workstations.

(F) Maintenance. Review and test the written policies and procedures required by this paragraph (a)(10)(ii) at least once every 12 months, and modify as reasonable and appropriate.

(11) Standard: Security awareness training —(i) General. Implement security awareness training for all workforce members on protection of electronic protected health information and information systems as necessary and appropriate for the members of the workforce to carry out their assigned function(s).

(ii) Implementation specifications —(A) Training. A covered entity or business associate must develop and implement security awareness training for all workforce members that addresses all of the following:

( 1) The written policies and procedures with respect to electronic protected health information required by this subpart as necessary and appropriate for the workforce members to carry out their assigned functions.

( 2) Guarding against, detecting, and reporting suspected or known security incidents, including but not limited to, malicious software and social engineering.

( 3) The written policies and procedures for accessing the covered entity's or business associate's relevant electronic information systems, including but not limited to: safeguarding passwords; setting unique passwords of sufficient strength to ensure the confidentiality, integrity, and availability of electronic protected health information; and limitations on sharing passwords.

(B) Timing. A covered entity or business associate must provide security awareness training as follows:

( 1) As required by paragraph (a)(11)(ii)(A) of this section, to each member of its workforce by no later than the compliance date, and at least once every 12 months thereafter.

( 2) As required by paragraph (a)(11)(ii)(A) of this section, to each new member of its workforce within a reasonable period of time but no later than 30 days after the person first has access to the covered entity's or business associate's relevant electronic information systems.

( 3) On a material change to the policies or procedures required by this subpart, to each member of its workforce whose functions are affected by such change, within a reasonable period of time but no later than 30 days after the material change occurs.

(C) Ongoing education. A covered entity or business associate must provide its workforce members ongoing reminders of their security responsibilities and notifications of relevant threats, including but not limited to new and emerging malicious software and social engineering.

(D) Documentation. A covered entity or business associate must document that the training required by paragraph (a)(11)(ii)(A) of this section and ongoing reminders required by paragraph (a)(11)(ii)(C) of this section have been provided.

(12) Standard: Security incident procedures —(i) General. Implement written policies and procedures to respond to security incidents.

(ii) Implementation specifications —(A) Planning and testing. ( 1) Establish written security incident response plan(s) and procedures documenting how workforce members are to report suspected or known security incidents and how the covered entity or business associate will respond to suspected or known security incidents in accordance with paragraph (a)(12)(ii)(B) of this section.

( 2) Implement written procedures for testing and revising security incident response plan(s) required by paragraph (a)(12)(ii)(A)( 1) of this section.

( 3) Review and test security incident response plan(s) and procedures required by paragraph (a)(12)(ii)(A)( 1) of this section at least once every 12 months, document the results of such tests, and modify security incident response plan(s) and procedures as reasonable and appropriate.

(B) Response. ( 1) Identify and respond to suspected or known security incidents.

( 2) Mitigate, to the extent practicable, harmful effects of security incidents that are suspected or known to the covered entity or business associate.

( 3) Identify and remediate, to the extent practicable, the root cause(s) of security incidents that are suspected or known to the covered entity or business associate.

( 4) Eradicate the security incidents that are suspected or known to the covered entity or business associate.

( 5) For suspected and known security incidents, develop and maintain documentation of investigations, analyses, mitigation, and remediation.

(13) Standard: Contingency plan —(i) General. Establish and implement as needed a written contingency plan, consisting of written policies and procedures for responding to an emergency or other occurrence—including but not limited to fire, vandalism, system failure, natural disaster, or security incident—that adversely affects relevant electronic information systems.

(ii) Implementation specifications —(A) Criticality analysis. Perform and document an assessment of the relative criticality of the covered entity's or business associate's relevant electronic information systems and technology assets in its relevant electronic information systems.

(B) Data backups. Establish and implement written procedures to create and maintain exact retrievable copies of electronic protected health information, including verification that the electronic protected health information has been copied accurately.

(C) Information systems backups. Establish and implement written procedures to create and maintain backups of the covered entity's or business associate's relevant electronic information systems, including verification of success of backups.

(D) Disaster recovery plan. ( 1) Establish (and implement as needed) written procedures to restore loss of the covered entity's or business associate's critical relevant electronic information systems and data within 72 hours of the loss.

( 2) Establish (and implement as needed) written procedures to restore loss of the covered entity's or business associate's other relevant electronic information systems and data in accordance with the criticality analysis required by paragraph (a)(13)(ii)(A) of this section.

(E) Emergency mode operation plan. Establish (and implement as needed) written procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.

(F) Testing and revision procedures. ( 1) Establish written procedures for testing and revising contingency plans as required by this paragraph (a)(13) in accordance with paragraph (a)(13)(ii)(F)( 2) of this section.

( 2) Review and test contingency plans required by this paragraph (a)(13) at least once every 12 months, document the results of such tests, and modify such contingency plans as reasonable and appropriate in accordance with the results of those tests. ( print page 1016)

(14) Standard: Compliance audit. Perform and document an audit at least once every 12 months of the covered entity's or business associate's compliance with each standard and implementation specification in this subpart.

(b)(1) Standard: Business associate contracts and other arrangements. (i)(A) A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will comply with this subpart and verifies that the business associate has deployed technical safeguards in accordance with the requirements of § 164.312.

(B) A covered entity is not required to obtain such satisfactory assurances or verification from a business associate that is a subcontractor.

(ii) A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with § 164.314(a), that the subcontractor will comply with the requirements of this subpart and verifies that the business associate that is a subcontractor has deployed technical safeguards in accordance with the requirements of § 164.312.

(2) Implementation specifications —(i) Written contract or other arrangement. Document the satisfactory assurances required by paragraph (b)(1)(i) or (ii) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a).

(ii) Written verification. Obtain written verification from the business associate at least once every 12 months that the business associate has deployed the technical safeguards as required by § 164.312 through both of the following:

(A) A written analysis of the business associate's relevant electronic information systems by a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of electronic protected health information to verify compliance with each standard and implementation specification in § 164.312.

(B) A written certification that the analysis has been performed and is accurate by a person who has the authority to act on behalf of the business associate.

(3) Standard: Delegation to business associate. (i) A covered entity or business associate may permit a business associate to serve as their designated security official.

(ii) A covered entity or business associate that delegates actions, activities, or assessments required by this subpart to a business associate remains liable for compliance with all applicable provisions of this subpart.

§ 164.310

Physical safeguards.

Each covered entity and business associate must, in accordance with §§ 164.306 and 164.316, implement all of the following physical safeguards to protect the confidentiality, integrity, and availability of all electronic protected health information that it creates, receives, maintains, or transmits:

(a) Standard: Facility access controls —(1) General. Establish and implement written policies and procedures to limit physical access to all of its relevant electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed.

(2) Implementation specifications —(i) Contingency operations. Establish (and implement as needed) written procedures that allow facility access in support of the covered entity's or business associate's contingency plan required by § 164.308(a)(13).

(ii) Facility security plan. Establish and implement written policies and procedures to safeguard all facilities and the equipment therein from unauthorized physical access, tampering, and theft.

(iii) Access management and validation procedures. Establish and implement written procedures to authorize and manage a person's access to facilities based on their role or function, including visitor management.

(iv) Physical maintenance records. Establish and implement written policies and procedures to document repairs and modifications to the physical components of a facility that are related to security, including but not limited to hardware, walls, doors, locks, and security cameras.

(v) Maintenance. For each facility, review and test the written policies and procedures required by this paragraph (a)(2) at least once every 12 months, and modify such policies and procedures as reasonable and appropriate.

(b) Standard: Workstation use —(1) General. Establish and implement written policies and procedures that govern the use of workstations that access electronic protected health information or the covered entity's or business associate's relevant electronic information systems.

(2) Implementation specifications —(i) Policies and procedures. The written policies and procedures must specify all of the following with respect to a workstation that accesses electronic protected health information or the covered entity's or business associate's relevant electronic information systems:

(A) The functions for which a workstation may be used.

(B) The manner in which a workstation may be used to perform those functions.

(C) The physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information, including the removal of such workstations from a facility and the movement of such workstations within and outside of a facility.

(ii) Maintenance. Review and test written policies and procedures at least once every 12 months, and modify as reasonable and appropriate.

(c) Standard: Workstation security. Implement and modify physical safeguards for all workstations that access electronic protected health information or relevant electronic information systems, to address the written policies and procedures for workstation use required by paragraph (b) of this section and restrict access to authorized users.

(d) Standard: Technology asset controls —(1) General. Establish and implement written policies and procedures that govern the receipt and removal of technology assets that maintain electronic protected health information into and out of a facility, and the movement of these assets within the facility.

(2) Implementation specifications —(i) Disposal. Establish and implement written policies and procedures for disposal of electronic protected health information and the technology assets on which it is maintained based on current standards for disposing of such technology assets.

(ii) Media sanitization. Establish and implement written procedures for removal of electronic protected health information from electronic media such that the electronic protected health information cannot be recovered, based on current standards for sanitizing electronic media before the media are made available for re-use.

(iii) Maintenance. Review and test the written policies and procedures required by paragraphs (d)(2)(i) and (ii) ( print page 1017) of this section at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

§ 164.312

Technical safeguards.

Each covered entity or business associate must, in accordance with §§ 164.306 and 164.316, implement all of the following technical safeguards, including technical controls, to protect the confidentiality, integrity, and availability of all electronic protected health information that it creates, receives, maintains, or transmits:

(a) Standard: Access control —(1) General. Deploy technical controls in relevant electronic information systems to allow access only to users and technology assets that have been granted access rights.

(2) Implementation specifications —(i) Unique identification. Assign a unique name, number, and/or other identifier for tracking each user and technology asset in the covered entity or business associate's relevant electronic information systems.

(ii) Administrative and increased access privileges. Separate user identities from identities used for administrative and other increased access privileges.

(iii) Emergency access procedure. Establish (and implement as needed) written and technical procedures for obtaining necessary electronic protected health information during an emergency.

(iv) Automatic logoff. Deploy technical controls that terminate an electronic session after a predetermined time of inactivity that is reasonable and appropriate.

(v) Log-in attempts. Deploy technical controls that disable or suspend the access of a user or technology asset to relevant electronic information systems after a reasonable and appropriate predetermined number of unsuccessful authentication attempts.

(vi) Network segmentation. Deploy technical controls to ensure that the covered entity's or business associate's relevant electronic information systems are segmented in a reasonable and appropriate manner.

(vii) Data controls. Deploy technical controls to allow access to electronic protected health information only to those users and technology assets that have been granted access rights to the covered entity's or business associate's relevant electronic information systems as specified in § 164.308(a)(10).

(viii) Maintenance. Review and test the effectiveness of the procedures and technical controls required by this paragraph (a)(2) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(b) Standard: Encryption and decryption —(1) General. Deploy technical controls to encrypt and decrypt electronic protected health information using encryption that meets prevailing cryptographic standards.

(2) Implementation specification. Encrypt all electronic protected health information at rest and in transit, except to the extent that an exception at paragraph (b)(3) of this section applies.

(3) Exceptions. This paragraph (b)(3) applies only to the electronic protected health information directly affected by one or more of the following exceptions and only to the extent that the covered entity or business associate documents that an exception applies and that all other applicable conditions are met.

(i) The technology asset in use does not support encryption of the electronic protected health information consistent with prevailing cryptographic standards, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports encryption consistent with prevailing cryptographic standards within a reasonable and appropriate period of time.

(ii) An individual requests pursuant to § 164.524 to receive their electronic protected health information in an unencrypted manner and has been informed of the risks associated with the transmission, receipt, and storage of unencrypted electronic protected health information. This exception does not apply where such individual will receive their electronic protected health information pursuant to § 164.524 and the technology used by the individual to receive the electronic protected health information is controlled by the covered entity or its business associate.

(iii) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems in which encryption is infeasible, and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with and determined by the covered entity's or business associate's contingency plan under § 164.308(a)(13).

(iv) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:

(A) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate deploys in a timely manner any updates or patches required or recommended by the manufacturer of the device.

(B) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.

(C) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.

(4) Alternative measures —(i) Alternative measures. Where an exception at paragraph (b)(3) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls in accordance with paragraph (b)(4)(ii) of this section.

(ii) Compensating controls. (A) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(i), (ii), or (iii) or (b)(3)(iv)(A) or (B) of this section applies, the covered entity or business associate must secure such electronic protected health information by implementing reasonable and appropriate compensating controls reviewed and approved by the covered entity's or business associate's designated Security Official.

(B) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(iv)(C) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.

(C) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (b)(4)(ii), the implementation and effectiveness of compensating controls must be reviewed, documented, and signed by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and relevant electronic information systems. ( print page 1018)

(5) Maintenance. Review and test the effectiveness of the technical controls required by this paragraph (b) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(c) Standard: Configuration management —(1) General. Establish and deploy technical controls for securing the covered entity's or business associate's relevant electronic information systems and technology assets in its relevant electronic information systems, including workstations, in a consistent manner, and maintain such electronic information systems and technology assets according to the covered entity's or business associate's established secure baselines.

(2) Implementation specifications —(i) Anti-malware protection. Deploy technology assets and/or technical controls that protect all of the covered entity's or business associate's technology assets in its relevant electronic information systems against malicious software, including but not limited to viruses and ransomware.

(ii) Software removal. Remove extraneous software from the covered entity's or business associate's relevant electronic information systems.

(iii) Configuration. Configure and secure operating system(s) and software consistent with the covered entity's or business associate's risk analysis under § 164.308(a)(2).

(iv) Network ports. Disable network ports in accordance with the covered entity's or business associate's risk analysis under § 164.308(a)(2).

(v) Maintenance. Review and test the effectiveness of the technical controls required by this paragraph (c) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(d) Standard: Audit trail and system log controls —(1) General. Deploy technology assets and/or technical controls that record and identify activity in the covered entity's or business associate's relevant electronic information systems.

(2) Implementation specifications —(i) Monitor and identify. The covered entity or business associate must deploy technology assets and/or technical controls that monitor in real-time all activity in its relevant electronic information systems, identify indications of unauthorized persons or unauthorized activity as determined by the covered entity's or business associate's risk analysis under § 164.308(a)(2), and alert workforce members of such indications in accordance with the policies and procedures required by § 164.308(a)(7).

(ii) Record. The covered entity or business associate must deploy technology assets and/or technical controls that record in real-time all activity in its relevant electronic information systems.

(iii) Retain. The covered entity or business associate must deploy technology assets and/or technical controls to retain records of all activity in its relevant electronic information systems as determined by the covered entity's or business associate's policies and procedures for information system activity review at § 164.308(a)(7)(ii)(A).

(iv) Scope. Activity includes creating, accessing, receiving, transmitting, modifying, copying, or deleting any of the following:

(A) Electronic protected health information.

(B) Relevant electronic information systems and the information therein.

(v) Maintenance. Review and test the effectiveness of the technology assets and/or technical controls required by this paragraph (d) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(e) Standard: Integrity. Deploy technical controls to protect electronic protected health information from improper alteration or destruction, both at rest and in transit; and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(f) Standard: Authentication —(1) General. Deploy technical controls to verify that a person or technology asset seeking access to electronic protected health information and/or the covered entity's or business associate's relevant electronic information systems is the one claimed.

(2) Implementation specifications —(i) Information access management policies. Deploy technical controls in accordance with the covered entity's or business associate's information access management policies and procedures under § 164.308(a)(10), including technical controls that require users to adopt unique passwords that are consistent with the current recommendations of authoritative sources.

(ii) Multi-factor authentication. (A) Deploy multi-factor authentication to all technology assets in the covered entity's or business associate's relevant electronic information systems to verify that a person seeking access to the relevant electronic information system(s) is the user that the person claims to be.

(B) Deploy multi-factor authentication for any action that would change a user's privileges to the covered entity's or business associate's relevant electronic information systems in a manner that would alter the user's ability to affect the confidentiality, integrity, or availability of electronic protected health information.

(iii) Exceptions. Deployment of multi-factor authentication is not required in any of the following circumstances.

(A) The technology asset in use does not support multi-factor authentication, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports multi-factor authentication within a reasonable and appropriate period of time.

(B) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems or the confidentiality, integrity, or availability of electronic protected health information in which multi-factor authentication is infeasible and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with its emergency access procedures under paragraph (a)(2)(iii) of this section and the covered entity's or business associate's contingency plan under § 164.308(a)(13).

(C) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:

( 1) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.

( 2) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.

( 3) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.

(iv) Alternative measures —(A) Alternative measures. Where an exception at paragraph (f)(2)(iii) of this ( print page 1019) section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls as required by paragraph (f)(2)(iv)(B) of this section.

(B) Compensating controls. ( 1) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(A) or (B) or (f)(2)(iii)(C)( 1) or ( 2) of this section applies, the covered entity or business associate must secure its relevant electronic information systems by implementing reasonable and appropriate compensating controls reviewed, approved, and signed by the covered entity's or business associate's designated Security Official.

( 2) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(C)( 3) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.

( 3) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (f)(2)(iv)(B), the effectiveness of compensating controls must be reviewed and documented by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and its relevant electronic information systems.

(v) Maintenance. Review and test the effectiveness of the technical controls required by this paragraph (f) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(g) Standard: Transmission security. Deploy technical controls to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network; and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(h) Standard: Vulnerability management —(1) General. Deploy technical controls in accordance with the covered entity's or business associate's patch management policies and procedures required by § 164.308(a)(4)(ii)(A) to identify and address technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems.

(2) Implementation specifications —(i) Vulnerability scanning. (A) Conduct automated vulnerability scans to identify technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2) or at least once every six months, whichever is more frequent.

(B) Review and test the effectiveness of the technology asset(s) that conducts the automated vulnerability scans required by paragraph (h)(2)(i)(A) of this section at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

(ii) Monitoring. Monitor authoritative sources for known vulnerabilities on an ongoing basis and remediate such vulnerabilities in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4).

(iii) Penetration testing. Perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person.

(A) A qualified person is a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of electronic protected health information.

(B) Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2), whichever is more frequent.

(iv) Patch and update installation. Deploy technical controls in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4) to ensure timely installation of software patches and critical updates as reasonable and appropriate.

(i) Standard: Data backup and recovery —(1) General. Deploy technical controls to create and maintain exact retrievable copies of electronic protected health information.

(2) Implementation specifications —(i) Data backup. Create backups of electronic protected health information in accordance with the policies and procedures required by § 164.308(a)(13)(ii)(B) and with such frequency to ensure retrievable copies of electronic protected health information are no more than 48 hours older than the electronic protected health information maintained in the covered entity or business associate's relevant electronic information systems.

(ii) Monitor and identify. Deploy technical controls that, in real-time, monitor, and alert workforce members about, any failures and error conditions of the backups required by paragraph (i)(2)(i) of this section.

(iii) Record. Deploy technical controls that record the success, failure, and any error conditions of backups required by paragraph (i)(2)(i) of this section.

(iv) Testing. Restore a representative sample of electronic protected health information backed up as required by paragraph (i)(2)(i) of this section, and document the results of such test restorations at least monthly.

(j) Standard: Information systems backup and recovery. Deploy technical controls to create and maintain backups of relevant electronic information systems; and review and test the effectiveness of such technical controls at least once every six months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.

§ 164.314

Organizational requirements.

(a)(1) Standard: Business associate contracts or other arrangements. The contract or other arrangement required by § 164.308(b)(2) must meet the requirements of paragraph (a)(2)(i), (ii), or (iii) of this section, as applicable.

(2) Implementation specifications —(i) Business associate contracts. The contract must provide that the business associate will do all of the following:

(A) Comply with the applicable requirements of this subpart.

(B) In accordance with § 164.308(b)(1)(ii), ensure that any subcontractors that create, receive, maintain, or transmit electronic protected health information on behalf of the business associate agree to comply with the applicable requirements of this subpart by entering into a contract or other arrangement that complies with this section.

(C) Report to the covered entity any security incident of which it becomes aware, including breaches of unsecured electronic protected health information as required by § 164.410.

(D) Report to the covered entity activation of its contingency plan under § 164.308(a)(13) without unreasonable ( print page 1020) delay, and in no case later than 24 hours after activation of the contingency plan.

(ii) Other arrangements. The covered entity is in compliance with paragraph (a)(1) of this section if it has another arrangement in place that meets the requirements of § 164.504(e)(3).

(iii) Business associate contracts with subcontractors. The requirements of paragraphs (a)(2)(i) and (ii) of this section apply to the contract or other arrangement between a business associate and a subcontractor required by § 164.308(b)(1)(ii) in the same manner as such requirements apply to contracts or other arrangements between a covered entity and business associate.

(b)(1) Standard: Requirements for group health plans. Except when the only electronic protected health information disclosed to a plan sponsor is disclosed pursuant to § 164.504(f)(1)(ii) or (iii), or as authorized under § 164.508, a group health plan must ensure that its plan documents provide that the plan sponsor will reasonably and appropriately safeguard electronic protected health information created, received, maintained, or transmitted to or by the plan sponsor on behalf of the group health plan.

(2) Implementation specifications. The plan documents of the group health plan must be amended to incorporate provisions to require the plan sponsor to do all of the following:

(i) Safeguard implementation. Implement the administrative, physical, and technical safeguards that covered entities and business associates are required to implement under §§ 164.308(a), 164.310, and 164.312.

(ii) Separation. Ensure that the adequate separation required by § 164.504(f)(2)(iii) is supported by the administrative, physical, and technical safeguards implemented in accordance with paragraph (b)(2)(i) of this section.

(iii) Agents. Ensure that any agent to whom it provides this information agrees to implement the administrative, physical, and technical safeguards in accordance with paragraph (b)(2)(i) of this section.

(iv) Security incident awareness. Report to the group health plan any security incident of which it becomes aware.

(v) Contingency plan activation. Report to the group health plan activation of its contingency plan, adopted in accordance with § 164.308(a)(13) as required by paragraph (b)(2)(i) of this section, without unreasonable delay and in no case later than 24 hours after activation of the contingency plan.

§ 164.316

Documentation requirements.

(a) Standard: Documentation. A covered entity or business associate must do all of the following in written form, which may be electronic, taking into consideration the factors in § 164.306(b):

(1) Document the policies and procedures required to comply with this subpart and how the covered entity or business associate considered the factors at § 164.306(b) in the development of such policies and procedures.

(2) Document each action, activity, or assessment required by this subpart.

(b) Implementation specifications —(1) Time limit. Retain the documentation required by paragraph (a) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.

(2) Availability. Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.

(3) Updates. Review and update documentation at least once every 12 months and within a reasonable and appropriate period of time after a security measure is modified.

§ 164.318

Transition provisions.

(a) Standard: Effect of prior contracts or other arrangements with business associates. Notwithstanding any other provisions of this subpart, a covered entity, or business associate with respect to a subcontractor, may allow a business associate to create, receive, maintain, or transmit electronic protected health information pursuant to a written contract or other arrangement with such business associate that does not comply with §§ 164.308(b) and 164.314(a), only in accordance with paragraph (b) of this section.

(b) Implementation specification: Deemed compliance —(1) Qualification. Notwithstanding other sections of this subpart, a covered entity, or business associate with respect to a subcontractor, is deemed to be in compliance with the documentation and contract requirements of §§ 164.308(b) and 164.314(a), with respect to a particular business associate relationship for the time period set forth in paragraph (b)(2) of this section, if both of the following apply:

(i) Prior to [DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal Register ], such covered entity, or business associate with respect to a subcontractor, has entered into and is operating pursuant to a written contract or other written arrangement with the business associate that complies with the applicable provisions of §§ 164.308(b) and 164.314(a) that were in effect on such date.

(ii) The contract or other arrangement is not renewed or modified from [DATE 60 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal Register ], until [DATE 240 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal Register ].

(2) Limited deemed compliance period. A prior contract or other arrangement that meets the qualification requirements at paragraph (b)(1) of this section shall be deemed compliant until the earlier of the following dates:

(i) The date such contract or other arrangement is renewed on or after [DATE 240 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal Register ].

(ii) [DATE 1 YEAR AND 60 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal Register ].

(c) Covered entity and business associate responsibilities. Nothing in this section shall alter the requirements of a covered entity or business associate to comply with applicable provisions of this part other than §§ 164.308(b) and 164.314(a).

§ 164.320

Severability.

If any provision of this subpart is held to be invalid or unenforceable by its terms, or as applied to any person or circumstance, or stayed pending further agency action, it shall be construed so as to give it maximum effect permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which event such provision shall be severable from this subpart and shall not affect the remainder thereof or the application of such provision to other persons not similarly situated or to other dissimilar circumstances.

( print page 1021)

Appendix A to Subpart C of Part 164—Security Standards: Matrix

Standards	Sections	Implementation specifications
Administrative Safeguards
Technology asset inventory	164.308(a)(1)	Inventory.
		Network map.
		Maintenance.
Risk analysis	164.308(a)(2)	Assessment
		Maintenance.
Evaluation	164.308(a)(3)	Performance
		Response.
Patch Management	164.308(a)(4)	Policies and procedures.
		Maintenance.
		Application.
		Exceptions.
		Alternative measures.
		Compensating controls.
Risk management	164.308(a)(5)	Planning.
		Maintenance.
		Priorities.
		Implementation.
Sanction policy	164.308(a)(6)	Policies and procedures.
		Modifications.
		Application.
Information system activity review	164.308(a)(7)	Policies and procedures.
		Scope.
		Record review.
		Record retention.
		Response.
		Maintenance.
Assigned security responsibility	164.308(a)(8)
Workforce security	164.308(a)(9)	Authorization and/or supervision.
		Workforce clearance procedure.
		Modification and termination procedures.
		Notification.
		Maintenance.
Information access management	164.308(a)(10)	Isolating health care clearinghouse functions.
		Access authorization.
		Authentication management.
		Access determination and modification.
		Network segmentation.
		Maintenance.
Security awareness training	164.308(a)(11)	Training.
		Timing.
		Ongoing education.
		Documentation.
Security incident procedures	163.308(a)(12)	Planning and testing.
		Response.
Contingency plan	163.308(a)(13)	Criticality analysis.
		Data backups.
		Information systems backups.
		Disaster recovery plan.
		Emergency mode operation plan.
		Testing and revision procedures.
Compliance audit	164.308(a)(14)
Business associate contracts and other arrangements	164.308(b)(1)	Written contract or other arrangement.
		Written verification.
Delegation to business associate	164.308(b)(3)
Physical Safeguards
Facility access controls	164.310(a)	Contingency operations.
		Facility security plan.
		Access management and validation procedures.
		Physical maintenance records.
		Maintenance.
Workstation use	164.310(b)	Policies and procedures.
		Maintenance.
Workstation security	164.310(c)
Technology asset controls	164.310(d)	Disposal.
		Media sanitization.
		Maintenance.
( print page 1022)
Technical Safeguards
Access control	164.312(a)	Unique identification.
		Administrative and increased access privileges.
		Emergency access procedure.
		Automatic logoff.
		Log-in attempts.
		Network segmentation.
		Data controls.
		Maintenance.
Encryption and decryption	164.312(b)	Implementation specification.
		Exceptions.
		Alternative measures.
		Compensating controls.
		Maintenance.
Configuration management	164.312(c)	Anti-malware protection.
		Software removal.
		Configuration.
		Network ports.
		Maintenance.
Audit trail and system log controls	164.312(d)	Monitor and identify.
		Record.
		Retain.
		Scope.
		Maintenance.
Integrity	164.312(e)
Authentication	164.312(f)	Information access management policies.
		Multi-factor authentication.
		Exceptions.
		Alternative measures.
		Compensating controls.
		Maintenance.
Transmission security	164.312(g)
Vulnerability management	164.312(h)	Vulnerability scanning.
		Monitoring.
		Penetration testing.
		Patch and update installation.
Data backup and recovery	164.312(i)	Data backup
		Monitor and identify.
		Record.
		Testing.
Information systems backup and recovery	164.312(j)