HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information

curity Rule A. Section 160.103—Definitions 1. Current Provision 2. Issues To Address 3. Proposals 4. Request for Comment B. Section 164.304—Definitions 1. Clarifying the Definition of “Access” 2. Clarifying the Definition of “Administrative Safeguards” 3. Clarifying the Definition of “Authentication” 4. Clarifying the Definition of “Availability” 5. Clarifying the Definition of “Confidentiality” 6. Adding Definitions of “Deploy” and “Implement” 7. Adding a Definition of “Electronic Information System” 8. Modifying the Definition of “Information System” 9. Modifying the Definition of “Malicious software” 10. Adding a Definition of “Multi-factor Authentication” (MFA) 11. Clarifying the Definition of “Password” 12. Clarifying the Definition of “Physical Safeguards” 13. Adding a Definition of “Relevant Electronic Information System” 14. Adding a Definition of “Risk” 15. Clarifying the Definitions of “Security or Security Measures” and “Security Incident” 16. Adding Definitions of “Technical Controls” 17. Modifying the Definition of “Technical Safeguards” 18. Adding a Definition of “Technology Asset” 19. Adding a Definition of “Threat” 20. Clarifying the Definition of “User” 21. Adding a Definition of “Vulnerability” 22. Clarifying the Definition of “Workstation” 23. Request for Comment C. Section 164.306—Security Standards: General Rules 1. Current Provisions 2. Issues To Address 3. Proposals 4. Request for Comment D. Section 164.308—Administrative Safeguards 1. Current Provisions 2. Issues To Address 3. Proposals 4. Request for Comment E. Section 164.310—Physical Safeguards 1. Current Provisions 2. Issues To Address 3. Proposals 4. Request for Comment F. Section 164.312—Technical Safeguards 1. Current Provisions 2. Issues To Address 3. Proposals 4. Request for Comment G. Section 164.314—Organizational Requirements 1. Section 164.314(a)(1)—Standard: Business Associate Contracts or Other Arrangements 2. Section 164.314(b)(1)—Standard: Requirements for Group Health Plans 3. Request for Comment H

e health care system.

8 See 68 FR 8334 (Feb. 20, 2003) and 78 FR 5566 (Jan. 25, 2013).

As discussed in greater detail below, in recent years, there has been an alarming growth in the number of breaches affecting 500 or more individuals reported to the Department, the overall number of individuals affected by such breaches, and the rampant escalation of cyberattacks using hacking and ransomware. The Department is concerned by the increasing numbers of breaches and other cybersecurity incidents experienced by regulated entities. We 9 are also increasingly concerned by the upward trend in the numbers of individuals affected by such incidents and the magnitude of the potential harms from such incidents. 10

9 In this NPRM, “we” and “our” denote the Department.

10 See “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.

In recognition of those potential harms and the health care sector's importance to the economy and security of the U.S., the President has designated “Healthcare and Public Health” as a critical infrastructure sector 11 and the Department as the Sector Risk Management Agency (SRMA). 12 In addition, to address concerns about the increasing level of cybercrime, the President has charged Federal agencies with “establishing and implementing minimum requirements for risk management” and robustly enforcing those requirements and Federal laws to help manage that risk. 13 We believe that a comprehensive and updated Security Rule is critical to accomplishing these directives and to the Department's effectiveness as the SRMA for the Healthcare and Public Health sector.

11 Presidential Memorandum on National Security Memorandum on Critical Infrastructure Security and Resilience, National Security Memorandum/NSM-22, The White House (Apr

s to help manage that risk. 13 We believe that a comprehensive and updated Security Rule is critical to accomplishing these directives and to the Department's effectiveness as the SRMA for the Healthcare and Public Health sector.

11 Presidential Memorandum on National Security Memorandum on Critical Infrastructure Security and Resilience, National Security Memorandum/NSM-22, The White House (Apr. 30, 2024), https://www.whitehouse.gov/briefing-room/presidential-actions/2024/04/30/national-security-memorandum-on-critical-infrastructure-security-and-resilience/ (“Critical infrastructure comprises 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.”).

12 Id. (charging an SRMA with serving as the primary Federal liaison to their designated critical infrastructure and “conduct[ing] sector-specific risk management and resilience activities”).

13 Id.

In further recognition of these concerns, States have promulgated or are in the process of promulgating regulations that would require the adoption of certain standards or measures for the protection of sensitive information, such as PHI. 14 While these proposed regulations may contain helpful guidance for regulated entities, none specifically focus on ensuring the security of ePHI and the information systems that create, receive, maintain, or transmit ePHI. Additionally, a patchwork of State-specific laws may create difficulties for regulated entities that are located or operate in multiple States. Several entities, including Federal agencies, have published and maintained guidelines, best practices, methodologies, procedures, and processes for protecting the security of sensitive information, including PHI

reate, receive, maintain, or transmit ePHI. Additionally, a patchwork of State-specific laws may create difficulties for regulated entities that are located or operate in multiple States. Several entities, including Federal agencies, have published and maintained guidelines, best practices, methodologies, procedures, and processes for protecting the security of sensitive information, including PHI. Some examples of these resources include the National Institute of Standards and Technology's (NIST's) “Cybersecurity Framework,” 15 the HHS 405(d) Program's “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients,” 16 the Federal Trade Commission's (FTC's) “Start with Security: A Guide for Business,” 17 and the Department's “Cybersecurity Performance Goals” (CPGs). 18 We believe that the proliferation of such documents in recent years has been helpful, and we have considered them in the development of this NPRM. However, in light of the increasing number and sophistication of cybersecurity incidents, we do not believe that these documents are sufficiently instructive for regulated entities to help improve their compliance with the Security Rule.

14 See, e.g., “New York State Register,” 46 N.Y. Reg. 7-10, Division of Administrative Rules, New York State Department of State (Oct. 2, 2024), https://dos.ny.gov/system/files/documents/2024/10/100224.pdf; “Invitation for Preliminary Comments on Proposed Rulemaking: Cybersecurity Audits, Risk Assessments, and Automated Decisionmaking,” California Privacy Protection Agency (Feb. 10, 2023), https://cppa.ca.gov/regulations/pdf/invitation_for_comments_pr_02-2023.pdf; see also Cal. Civ. Code Section 1798.185.

15 “The NIST Cybersecurity Framework (CSF) 2.0,” National Institute of Standards and Technology, U.S. Department of Commerce (Feb. 26, 2024), https://doi.org/10.6028/NIST.CSWP.29.

16 “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients,” U.S

20 we believe that it would be appropriate to consider modifying the Security Rule to address the following:

19 Sec. 1174(b)(1) of the SSA; 45 CFR 160.104.

20 See sec. 261 of Public Law 104-191, 110 Stat. 1936 (codified at 42 U.S.C. 1320d note).

• Significant changes in technology.

• Changes in breach trends and cyberattacks.

• HHS' Office for Civil Rights' (OCR's) enforcement experience.

• Other guidelines, best practices, methodologies, procedures, and processes for protecting ePHI.

• Court decisions that affect enforcement of the Security Rule.

B. Applicability

The effective date of a final rule would be 60 days after publication. 21 Regulated entities would have until the “compliance date” to establish and implement policies, procedures, and practices to achieve compliance with any new or modified standards.

Regulated entities would be permitted to comply earlier than the compliance date, but the Department would not take action against them for noncompliance with the proposed changes that occurs before the compliance date. Except as otherwise provided, 45 CFR 160.105 provides that regulated entities must comply with the applicable new or modified standards or implementation specifications no later than 180 days from the effective date of any such change. The Department has previously noted that the 180-day general compliance period for new or modified standards would not apply where a different compliance period is provided in the regulation for one or more provisions. 22 However, the compliance period cannot be less than the statutory minimum of 180 days. 23

21 See “A Guide to the Rulemaking Process,” Office of the Federal Register (2011), p. 8, https://www.federalregister.gov/uploads/2011/01/the_rulemaking_process.pdf.

22 See 78 FR 5566, 5569 (Jan. 25, 2013).

23 See 42 U.S.C. 1320d-4(b)(2)

period is provided in the regulation for one or more provisions. 22 However, the compliance period cannot be less than the statutory minimum of 180 days. 23

21 See “A Guide to the Rulemaking Process,” Office of the Federal Register (2011), p. 8, https://www.federalregister.gov/uploads/2011/01/the_rulemaking_process.pdf.

22 See 78 FR 5566, 5569 (Jan. 25, 2013).

23 See 42 U.S.C. 1320d-4(b)(2).

While we recognize that we are proposing to substantially revise the regulatory text, the Department believes that most of the existing Security Rule's obligations for regulated entities would not be substantially changed by the proposed modifications. Instead, the proposed modifications would explicitly codify those activities that are critical to protecting the security of ePHI as requirements and provide greater detail for such requirements in the regulatory text. For example, regulated entities are already required to conduct an accurate and thorough risk analysis. While not specified in the regulatory text of the Security Rule, an accurate and thorough risk analysis requires a regulated entity to perform an inventory of its technology assets, determine how ePHI moves through its information systems, and identify the locations within its information systems (or components thereof) where ePHI may be created, received, maintained, or transmitted. Applying such an approach protects ePHI across all phases of the data lifecycle consistent with the purpose of the Security Rule. The proposals to require a regulated entity to inventory its technology assets and map the movement of ePHI through its information systems would illuminate considerations to be included in the regulated entity's risk analysis.

As another example, implementing a mechanism to encrypt ePHI is an addressable implementation specification under the standard for access control at 45 CFR 164.312(a)(2)(iv)

nd eliminate the need for regulated entities to perform an analysis of whether encryption is reasonable and appropriate.

24 45 CFR 164.306(d)(3)(i) and (d)(3)(ii)(A).

25 45 CFR 164.306(d)(3)(ii)(B).

Thus, most of the modifications we are proposing would provide regulated entities with greater clarity and specificity regarding how to fulfill their obligations and the Department's expectations.

Accordingly, we do not believe that the proposed rule would pose unique implementation challenges that would justify an extended compliance period ( i.e., a period longer than the standard 180 days provided in 45 CFR 160.105). Further, the Department believes that adherence to the standard compliance period is necessary to timely address the circumstances described in this NPRM. Thus, the Department proposes to apply the standard compliance date of 180 days after the effective date of a final rule. 26

26 See 45 CFR 160.104(c)(1), which requires the Secretary to provide at least a 180-day period for regulated entities to comply with modifications to standards and implementation specifications in the HIPAA Rules.

To help reduce administrative burdens on regulated entities, the Department proposes to add a provision at 45 CFR 164.318 affording regulated entities a transition period (beyond the 180-day compliance period) to modify business associate contracts (herein referred to as “business associate agreements”) or other written arrangements 27 that would qualify for the longer transition period, as discussed further below.

27 45 CFR 164.314(a)(1).

The Department seeks comment on the proposed compliance period and transition period.

C. Table of Abbreviations/Commonly Used Acronyms in This Document

As used in this preamble, the following terms and abbreviations have the meanings noted below.

Term Meaning AI Artificial Intelligence. ANSI American National Standards Institute. AR Augmented Reality. ARRA American Recovery and Reinvestment Act of 2009

1 note).

29 See H.R. Rep. No. 104-496, at 66-67 (1996).

30 Public Law 104-191, 110 Stat. 1936 (Aug. 21, 1996).

31 Sec. 262(a) of Public Law 104-191, 110 Stat. 2021 (Aug. 21, 1996) (codified at 42 U.S.C. 1320d).

32 Sec. 261 of Public Law 104-191, 110 Stat. 2021 (Aug. 21, 1996), as amended by sec. 1104(a) of Public Law 111-148, 124 Stat. 146 (Mar. 23, 2010) (codified at 42 U.S.C. 1320d note).

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

33 On a resolution waiving points of order against the Conference Report to H.R. 3103, members debated an “erosion of privacy” balanced against the administrative simplification provisions. Thus, from HIPAA's inception, privacy has been a central concern to be addressed as legislative changes eased disclosures of PHI. See 142 Cong. Rec. H9777 and H9780.

34 142 Cong. Rec. S9515-16 (daily ed. Aug. 2, 1996) (statement of Sen. Simon).

35 See H.R. Rep. No

ference Report to H.R. 3103, members debated an “erosion of privacy” balanced against the administrative simplification provisions. Thus, from HIPAA's inception, privacy has been a central concern to be addressed as legislative changes eased disclosures of PHI. See 142 Cong. Rec. H9777 and H9780.

34 142 Cong. Rec. S9515-16 (daily ed. Aug. 2, 1996) (statement of Sen. Simon).

35 See H.R. Rep. No. 104-496 Part 1, at 99-100 (Mar. 25, 1996).

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

36 See sec. 262(a) of Public Law 104-191, 110 Stat. 2021, adding section 1172 to the SSA (codified at 42 U.S.C. 1320d-1); see also section 13404 of the American Recovery and Reinvestment Act (ARRA) of 2009, Public Law 111-5, 123 Stat. 115 (Feb. 17, 2009) (codified at 42 U.S.C. 17934) (applying privacy provisions and penalties to business associates of covered entities). The Department codified the term “covered entity” and defined it using these three categories of persons. 45 CFR 164.103.

37 42 U.S.C. 1320d-2(d)(2).

38 42 U.S.C. 1320d-2(d)(2)(A).

39 42 U.S.C. 1320d-2(d)(2)(B).

40 42 U.S.C. 1320d-2(d)(2)(C)

o 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

45 Id.

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

46 Sec. 262(a) of Public Law 104-191, 110 Stat. 2026, adding sec. 1174(b)(1) (codified at 42 U.S.C. 1320d-3).

47 Sec. 1102 of the SSA (codified at 42 U.S.C. 1302).

48 Sec. 262(a) of Public Law 104-191, 110 Stat. 2023, adding sec. 1172 (codified at 42 U.S.C. 1320d-1).

49 Id.

2

on Vital and Health Statistics (NCVHS) and consult with Federal and State agencies and private organizations. 49

46 Sec. 262(a) of Public Law 104-191, 110 Stat. 2026, adding sec. 1174(b)(1) (codified at 42 U.S.C. 1320d-3).

47 Sec. 1102 of the SSA (codified at 42 U.S.C. 1302).

48 Sec. 262(a) of Public Law 104-191, 110 Stat. 2023, adding sec. 1172 (codified at 42 U.S.C. 1320d-1).

49 Id.

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

50 Title XIII of Division A and title IV of Division B of ARRA of 2009, Public Law 111-5, 123 Stat. 115 (Feb. 17, 2009) (codified at 42 U.S.C. 201 note).

51 Id.; see also Subtitle B of title XIII of the HITECH Act (codified at 42 U.S.C. 17911-17912), 42 U.S.C

t also introduced substantial changes to the HIPAA regulations by mandating stronger safeguards for the privacy and security of ePHI. 55

50 Title XIII of Division A and title IV of Division B of ARRA of 2009, Public Law 111-5, 123 Stat. 115 (Feb. 17, 2009) (codified at 42 U.S.C. 201 note).

51 Id.; see also Subtitle B of title XIII of the HITECH Act (codified at 42 U.S.C. 17911-17912), 42 U.S.C. 300jj-31-38.

52 See H.R. Rep. No. 111-7, at 74 (2009), accompanying H.R. 629, 111th Cong.

53 H.R. 629, Energy and Commerce Recovery and Reinvestment Act of 2009, introduced in the House on Jan. 22, 2009, contained nearly identical provisions to subtitle D of the HITECH Act.

54 C. Stephen Redhead, “The Health Information Technology for Economic and Clinical Health (HITECH) Act,” Congressional Research Service, p. 8 (2009), https://crsreports.congress.gov/product/pdf/R/R40161/9; id. at 9 (“[Health IT], which generally refers to the use of computer applications in medical practice, is widely viewed as a necessary and vital component of health care reform.”).

55 Subtitle D of title XIII of the HITECH Act (codified at 42 U.S.C. 17921, 42 U.S.C. 17931-17941, and 42 U.S.C. 17951-17953).

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

56 See S. Rept. 111-3, 111th Cong

ry 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

62 See Public Law 116-321, 134 Stat. 5072, adding sec. 13412 (Jan. 5, 2021) (codified at 42 U.S.C. 17941); see also 42 U.S.C. 17931 et seq.

63 See Public Law 116-321, 134 Stat. 5072, adding sec. 13412 (Jan. 5, 2021) (codified at 42 U.S.C. 17941); see also sec. 13401 of Public Law 111-5, 123 Stat. 260 (codified at 42 U.S.C. 17931) (The HITECH Act adopts the same definition of business associate as the HIPAA Rules.); 45 CFR 160.103 (definition of “Business associate”).

B. Regulatory History

The Security Rule requires regulated entities to implement administrative, physical, and technical safeguards to

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

64 The Security Rule is codified at 45 CFR part 160 and subparts A and C of 45 CFR part 164.

65 See 45 CFR 164.306(a)(1).

66 See 45 CFR 164.306(a)(2).

67 See 45 CFR 164.306(a)(3).

68 See 45 CFR 164.306(a)(4).

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

69 See sec. 262(a) of Public Law 104-191, 110 Stat. 2025 (Aug

tructed 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

69 See sec. 262(a) of Public Law 104-191, 110 Stat. 2025 (Aug. 21, 1996), adding sec. 1173(d) (codified at 42 U.S.C. 1320d-2(d)).

70 63 FR 43242 (Aug. 12, 1998).

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

71 Id. at 43244.

72 Id. at 43244, 43249, 43260-61.

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

ons 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

92 Id.

93 Id. at 8336.

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

94 “Statement of Organization, Functions, and Delegations of Authority,” Centers for Medicare & Medicaid Services, 68 FR 60694 (Oct. 23, 2003).

95 “Office for Civil Rights; Delegation of Authority,” U.S. Department of Health and Human Services, 74 FR 38630 (Aug. 4, 2009); see also “Statement of Organization, Functions, and Delegations of Authority,” Centers for Medicare & Medicaid Services, 74 FR 38663 (Aug. 4, 2009).

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

96 75 FR 40868 (July 14, 2010)

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

96 75 FR 40868 (July 14, 2010).

97 Id. at 40871.

98 Id.

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.

99 78 FR 5565 (Jan. 25, 2013). In addition to finalizing requirements of the HITECH Act that were proposed in the NPRM, the Department adopted modifications to the Enforcement Rule not previously adopted in an earlier interim final rule, 74 FR 56123 (Oct. 30, 2009), and to the Breach Notification Rule not previously adopted in an interim final rule, 74 FR 42739 (Aug. 24, 2009). The Department also finalized previously proposed Privacy Rule modifications as required by the Genetic Information Nondiscrimination Act of 2008, 74 FR 51698 (Oct. 7, 2009).

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

tion Nondiscrimination Act of 2008, 74 FR 51698 (Oct. 7, 2009).

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

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.

100 78 FR 5565, 5589 (Jan. 25, 2013).

101 Sec. 13401 of Public Law 111-5, 123 Stat. 260 (Feb. 17, 2009) (codified at 42 U.S.C. 17931).

102 78 FR 5565, 5590 (Jan. 25, 2013); see also 45 CFR 164.314(a).

103 78 FR 5565, 5589 (Jan. 25, 2013).

104 68 FR 8334, 8341 (Feb. 20, 2003).

105 78 FR 5565, 5589 (Jan. 25, 2013).

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

106 Id. at 5590.

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

associate of the covered entity must obtain the required satisfactory assurances from the subcontractor to protect the security of ePHI. 107

107 Id. (citing 45 CFR 164.308(b)).

III

nd cybercriminals have become more sophisticated, protective measures, including technology, have been developed to prevent and mitigate such risks. For example, certain health IT may be certified through the ONC Health IT Certification Program as meeting certain criteria that address the security of information created, received, maintained, or transmitted by that health IT. See 45 CFR 170.550(h).

109 45 CFR 164.306(b).

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.

110 45 CFR 164.310(a)(1).

111 45 CFR 164.310(a)(2).

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

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.

112 “National Trends in Hospital and Physician Adoption of Electronic Health Records,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.

113 See “2020-2025 Federal Health IT Strategic Plan,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 6 (Oct. 2020), https://www.healthit.gov/sites/default/files/page/2020-10/Federal%20Health%20IT%20Strategic%20Plan_2020_2025.pdf

ov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.

113 See “2020-2025 Federal Health IT Strategic Plan,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 6 (Oct. 2020), https://www.healthit.gov/sites/default/files/page/2020-10/Federal%20Health%20IT%20Strategic%20Plan_2020_2025.pdf.

114 Among other things, the Cures Act provided ONC, in collaboration with NIST and other relevant agencies within the Department, with the authority to convene public-private and public-public partnerships to build consensus and develop or support a trusted exchange framework, including a common agreement among health information networks nationally. The purpose of this work is to ensure full network-to-network exchange of health information. Sec. 4003(b) of Public Law 114-255, 130 Stat. 1165 (Dec. 13, 2016) (codified at 42 U.S.C. 300jj-11(c)). The Cures Act also provides penalties for any developer of certified health IT, health information exchange or network, and appropriate disincentives for any health care provider, determined by the Inspector General to have committed information blocking. Sec. 4004(b)(2) of Public Law 114-255, 130 Stat. 1165 (Dec. 13, 2016) (codified at 42 U.S.C. 300jj-52).

115 See “Frequently Asked Question: Health Information Exchange: The Benefits,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, https://www.healthit.gov/faq/why-health-information-exchange-important.

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

on Technology, U.S. Department of Health and Human Services, https://www.healthit.gov/faq/why-health-information-exchange-important.

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.

116 See Genevieve P. Kanter, et al., “Beyond Security Patches—Fundamental Incentive Problems in Health Care Cybersecurity,” JAMA Health Forum, Volume 2, Issue 10, p. e212969 (Oct. 8, 2021), https://jamanetwork.com/journals/jama-health-forum/fullarticle/2784981; Chon Abraham, et al., “Muddling through cybersecurity: Insights from the U.S. healthcare industry,” Business Horizons, Volume 62, Issue 4, p. 539-548, p. 539 (July-Aug. 2019), https://www.sciencedirect.com/science/article/abs/pii/S0007681319300436; Eric Perakslis, “Responding to the Escalating Cybersecurity Threat to Health Care,” The New England Journal of Medicine, Volume 387, Issue 9 (Sept. 1, 2022), https://www.nejm.org/doi/abs/10.1056/NEJMp2205144; Anthony James Cartwright, “The elephant in the room: cybersecurity in healthcare,” Journal of Clinical Monitoring and Computing, Volume 37, Issue 5, p. 1123-1132 (Apr. 24, 2023), https://link.springer.com/article/10.1007/s10877-023-01013-5.

117 “Report on Improving Cybersecurity In The Health Care Industry,” Health Care Industry Cybersecurity Task Force, p. 1 (June 2017), https://www.phe.gov/preparedness/planning/cybertf/documents/report2017.pdf.

Despite advancements in technology, including health IT, the core requirements of the Security Rule remain relevant and applicable today

.springer.com/article/10.1007/s10877-023-01013-5.

117 “Report on Improving Cybersecurity In The Health Care Industry,” Health Care Industry Cybersecurity Task Force, p. 1 (June 2017), https://www.phe.gov/preparedness/planning/cybertf/documents/report2017.pdf.

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

Threats and Protecting Patients,” 119 and the Department's CPGs. 120

118 “The NIST Cybersecurity Framework (CSF) 2.0,” supra note 15.

119 “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients,” supra note 16.

120 “Cybersecurity Performance Goals,” supra note 18.

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

a (May 10, 2022), https://ncvhs.hhs.gov/wp-content/uploads/2022/05/NCVHS-Recommendations-to-Strengthen-Cybersecurity-in-HC-05-10-2022-508.pdf; see also Letter from NCVHS Chair Jacki Monson to HHS Secretary Xavier Becerra (Nov. 29, 2023), https://ncvhs.hhs.gov/wp-content/uploads/2024/01/Letter-to-the-Secretary-Recommendations-to-Strengthen-the-HIPAA-Security-Rule_508.pdf.

124 42 U.S.C. 1320d-1(f).

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

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

125 Subtitle F of title II of HIPAA, Public Law 104-191, 110 Stat. 1936 (Aug. 21, 1996).

126 Sec. 261 of Public Law 104-191, 110 Stat. 2021 (Aug. 21, 1996), as amended by sec. 1104(a) of Public Law 111-148, 124 Stat. 146 (Mar. 23, 2010) (codified at 42 U.S.C. 1320d note).

127 See statement of Sen. Simon, supra note 34; see also 155 Cong. Rec. H1562 (statement of Rep. Markey) (stating that ARRA includes provisions for health IT with built-in privacy and security); Implementation of the Health Information Technology for Economic and Clinical Health (HITECH) Act: Hearing Before the House Committee on Energy and Commerce Subcommittee on Health, 111th Cong. 11-12 (2010) (statement of Rep. Schakowsky) (explaining that the HITECH Act strengthened Federal privacy and security laws to protect personal identifying information from misuse to ensure that individuals would be willing to use electronic records).

128 Statement of Sen. Simon, supra note 34

TECH) Act: Hearing Before the House Committee on Energy and Commerce Subcommittee on Health, 111th Cong. 11-12 (2010) (statement of Rep. Schakowsky) (explaining that the HITECH Act strengthened Federal privacy and security laws to protect personal identifying information from misuse to ensure that individuals would be willing to use electronic records).

128 Statement of Sen. Simon, supra note 34.

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

129 See section 1173(d)(2) of HIPAA (codified at 42 U.S.C. 1320d-2(d)(2)) and section 13401 of ARRA (codified at 42 U.S.C. 17931(a)) and 45 CFR 164.306.

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

ther 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

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

130 See Hadi Ghayoomi, et al., “Assessing resilience of hospitals to cyberattack,” Digital Health, p. 2 (2021), https://doi.org/10.1177/20552076211059366; “Beyond Security Patches-Fundamental Incentive Problems in Health Care Cybersecurity,” supra note 116; Jessica Brewer, et al., “An Insight into the Current Security Posture of Healthcare IT: A National Security Concern,” The Institute for Critical Infrastructure Technology, p. 3 (2019), https://www.icitech.org/post/an-insight-into-the-current-security-posture-of-healthcare-it-a-national-security-concern.

131 “Cost of a Data Breach Report 2023,” IBM, p. 13 (2023) (explaining that the average cost of a health care data breach was $7.13 million in 2020), https://www.ibm.com/reports/data-breach

luded survey responses from 648 IT and IT security practitioners at U.S.-based health care organizations.).

144 Id. at p. 5.

145 See Letter from NCVHS Chair Jacki Monson (2023), supra note 123, p. 1 (citing several media reports that attributed patient deaths to cybersecurity attacks).

146 Id. (citing Joseph Marks, “Ransomware attack might have caused another death,” The Washington Post (Oct. 1, 2021), https://www.washingtonpost.com/politics/2021/10/01/ransomware-attack-might-have-caused-another-death/ ).

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

147 “Assessing resilience of hospitals to cyberattack,” supra note 130, p. 2.

148 Kerri Reeves, “Cyberattacks: Not a Matter of If, but When,” Radiology Matters (Mar./Apr. 2024), https://www.proquest.com/scholarly-journals/cyberattacks-not-matter-if-when/docview/2957757956/se-2?accountid=12786.

149 Id.

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

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

156 On July 29, 2024, the Department announced that the Office of the National Coordinator for Health Information Technology was being renamed the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology. In this NPRM, we continue to use ONC for publications cited that predate the renaming of that office. 89 FR 60903 (July 29, 2024).

157 See, e.g., 45 CFR 170.315(d)(6), (7), (12), and (13). For more information on the ONC Health IT Certification Program, visit https://www.healthit.gov/topic/certification-ehrs/certification-health-it.

158 The ONC Health IT Certification Program specifies at 45 CFR 170.550(h) the privacy and security certification framework for Health IT Modules. Section 170.550(h) identifies a mandatory minimum set of the certification criteria that ONC-Authorized Certification Bodies (ONC ACBs) must ensure are also included as part of specific Health IT Modules that are presented for certification

health-it.

158 The ONC Health IT Certification Program specifies at 45 CFR 170.550(h) the privacy and security certification framework for Health IT Modules. Section 170.550(h) identifies a mandatory minimum set of the certification criteria that ONC-Authorized Certification Bodies (ONC ACBs) must ensure are also included as part of specific Health IT Modules that are presented for certification. See “Certification Companion Guide Privacy and Security,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services (May 7, 2024), https://www.healthit.gov/sites/default/files/2015Ed_CCG_Privacy_and_Security.pdf.

159 See 45 CFR 171.102 (definition of “Electronic health information”).

160 See, e.g., Medicare Promoting Interoperability Program, 42 CFR 495.24 (eligible hospitals and critical access hospitals must use certified electronic health record technology (CEHRT), with limited exceptions, to comply with the program's meaningful use requirements); Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category, 42 CFR 414.1375 (requiring MIPS eligible clinicians to use CEHRT, as defined in 42 CFR 414.1305, to comply with reporting requirements for the Promoting Interoperability performance category).

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

ng 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

confidentiality, integrity, and availability of sensitive and confidential information, including ePHI.

161 See, e.g., “Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients,” supra note 16.

162 See, e.g., “The NIST Cybersecurity Framework (CSF) 2.0,” supra note 15.

163 See, e.g., “Cybersecurity Performance Goals,” supra note 18.

164 See, e.g., “Cross-Sector Cybersecurity Performance Goals,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security (Mar. 2023), https://www.cisa.gov/sites/default/files/2023-03/CISA_CPG_REPORT_v1.0.1_FINAL.pdf.

165 See generally 45 CFR 164.308(a); “The NIST Cybersecurity Framework (CSF) 2.0,” supra note 15; “Cybersecurity Performance Goals,” supra note 18.

A major distinguishing factor between the content of the Security Rule and these compilations and regulations is the Security Rule's scope

land Security (Mar. 2023), https://www.cisa.gov/sites/default/files/2023-03/CISA_CPG_REPORT_v1.0.1_FINAL.pdf.

165 See generally 45 CFR 164.308(a); “The NIST Cybersecurity Framework (CSF) 2.0,” supra note 15; “Cybersecurity Performance Goals,” supra note 18.

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

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

.S.C. 300jj-11(c) and 42 U.S.C. 300jj-52).

171 Dustin Charles, et al., “ONC Data Brief: Interoperability among U.S. Non-federal Acute Care Hospitals, 2014,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 1 (Aug. 2015), https://www.healthit.gov/sites/default/files/briefs/onc_databrief25_interoperabilityv16final_081115.pdf.

172 Meghan Hufstader Gabriel, et al., “ONC Data Brief: Interoperable Exchange of Patient Health Information Among U.S. Hospitals: 2023,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 1 (May 2024), https://www.healthit.gov/sites/default/files/2024-05/Interoperable-Exchange-of-Patient-Health-Information-Among-U.S.-Hospitals-2023.pdf.

173 Wesley Barker, et al., “ONC Data Brief: Hospital Capabilities to Enable Patient Electronic Access to Health Information, 2021,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 2 and 5 (Oct. 2022) (estimates based on non-Federal acute care hospitals and applications configured to meet the application programming interface (API) specifications in the hospital's EHR), https://www.healthit.gov/sites/default/files/2022-12/hospital_capabilities_to_enable_patient_access_ONC_DB2021-Updated.pdf.

174 Catherine Strawley, et al., “ONC Data Brief: Hospital Use of APIs to Enable Data Sharing Between EHRs and Apps,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 2 (Sept. 2023) (estimates based on non-Federal acute care hospitals using standards-based APIs to enable patient access), https://www.healthit.gov/sites/default/files/2023-09/DB68-Hospital%20Use%20of%20APIs%20to%20Enable%20Data%20Sharing_508.pdf.

Not only is PHI increasingly maintained and transmitted electronically, but treatment is also increasingly provided electronically

Civil Rights, U.S. Department of Health and Human Services (Jan. 20, 2021), https://www.hhs.gov/hipaa/for-professionals/special-topics/emergency-preparedness/notification-enforcement-discretion-telehealth/index.html.

176 Yuriy Pylypchuk, et al., “ONC Data Brief: Use of Telemedicine among Office-Based Physicians, 2021,” The Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, p. 1 (Mar. 2023), https://www.healthit.gov/sites/default/files/2023-04/DB65_TelemedicinePhysicians_508.pdf.

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

177 Nduma N. Basil, “Health Records Database and Inherent Security Concerns: A Review of the Literature,” Cureus, p. 3 (Oct. 11, 2022) (“The increase in networked medical equipment and devices implies that, if there is a security breach in the form of hacking, then traffic on the network can slow down and interfere with the delivery of healthcare services.”), https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9647912/.

178 Id

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

180 Elizabeth Gourd, “Increase in health-care cyberattacks affecting patients with cancer,” The Lancet, p. 1215 (Sept. 2021), https://doi.org/10.1016/S1470-2045(21)00451-4.

181 See Mayo Clinic, https://www.mayoclinic.org/.

182 An “ethical hacker” is a cybersecurity researcher who “use[s] penetration testing techniques to test an organization's cybersecurity and information technology (IT) security.” See Ed Tittel, “How to Become a White Hat Hacker,” Business News Daily (June 17, 2024), https://www.businessnewsdaily.com/10713-white-hat-hacker-career.html.

183 See Foued Badrouchi, et al., “Cybersecurity Vulnerabilities in Biomedical Devices: A Hierarchical Layered Framework,” Internet of Things Use Cases for the Healthcare Industry, p. 157-58 (2020); see also Monte Reel, et al., “It's Way Too Easy to Hack the Hospital,” Bloomberg Businessweek (Nov. 2015), https://www.bloomberg.com/features/2015-hospital-hack/.

184 See “Cybersecurity Vulnerabilities in Biomedical Devices: A Hierarchical Layered Framework,” supra note 183, p. 157-58

existing data to either reorganize existing data or create new content.” “Risk In Focus: Generative A.I. And The 2024 Election Cycle,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/sites/default/files/2024-05/Consolidated_Risk_in_Focus_Gen_AI_ElectionsV2_508c.pdf.

201 “2023 HIMSS Healthcare Cybersecurity Survey,” supra note 199, p. 22.

202 See Lizzie Roehrs, “CSL Professor explores DNA as data storage,” University of Illinois Urbana-Champaign The Grainger College of Engineering Coordinated Science Laboratory (Aug. 25, 2020), https://csl.illinois.edu/news-and-media/csl-professor-explores-dna-data-storage; Cheng Kai Lim, et al., “A biological camera that captures and stores images directly into DNA,” nature communications (July 3, 2023), https://www.nature.com/articles/s41467-023-38876-w; Devasier Bennet, et al., “Current and emerging opportunities in biological medium-based computing and digital data storage,” Nano Select, p. 883 (May 2022), https://doi-org.hhsnih.idm.oclc.org/10.1002/nano.202100275.

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

index.html; “About the HHS Office of the Chief Artificial Intelligence Officer (OCAIO),” U.S. Department of Health and Human Services (June 6, 2024), https://www.hhs.gov/programs/topic-sites/ai/ocaio/index.html; see also “Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence,” M-24-10, Office of Management and Budget, Executive Office of the President (Mar. 28, 2024), https://www.whitehouse.gov/wp-content/uploads/2024/03/M-24-10-Advancing-Governance-Innovation-and-Risk-Management-for-Agency-Use-of-Artificial-Intelligence.pdf.

206 See, e.g., 89 FR 37522, 37642 (May 6, 2024) and 89 FR 1192, 1244 (Jan. 9, 2024).

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

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

th Systems (June 17, 2024), https://link.springer.com/article/10.1007/s44250-024-00105-6#:~:text=Specifically%2C%20our%20study%20shows%20that,trend%20of%20breaches%20over%20time.

209 Lynne Coventry, et al., “Cybersecurity in healthcare: A narrative review of trends, threats and ways forward,” Maturitas, p. 46 (July 2018), https://www.maturitas.org/article/S0378-5122(18)30165-8/abstract.

210 Id.

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

211 See “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,” supra note 10.

212 Id.

213 “Annual Report to Congress on Breaches of Unsecured Protected Health Information: For Calendar Year 2022,” Office for Civil Rights, U.S. Department of Health and Human Services, p. 8-9 (2022), https://www.hhs.gov/sites/default/files/breach-report-to-congress-2022.pdf.

214 Change Healthcare is a health care clearinghouse and a subsidiary of UnitedHealth Group, https://www.changehealthcare.com/. On the morning of Feb

.S. health care sector increased 128 percent. 218

215 “internet Crime Report,” internet Crime Complaint Center, Federal Bureau of Investigation, p. 13 (2023), https://www.ic3.gov/Media/PDF/AnnualReport/2023_IC3Report.pdf.

216 “Report on Improving Cybersecurity In The Health Care Industry,” supra note 117, p. 16.

217 Chon Abraham, et al., “Muddling through cybersecurity: Insights from the U.S. healthcare industry,” supra note 116, p. 539-548, 540.

218 “Ransomware Attacks Surge in 2023; Attacks on Healthcare Sector Nearly Double,” The Cyber Threat Intelligence Integration Center, Office of the Director of National Intelligence (Feb. 28, 2024), https://www.dni.gov/files/CTIIC/documents/products/Ransomware_Attacks_Surge_in_2023.pdf.

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

219 “Report on Improving Cybersecurity In The Health Care Industry,” supra note 117, p. 14.

220 Id.

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

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

221 Presidential Memorandum on National Security Memorandum on Critical Infrastructure Security and Resilience supra note 11.

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

internal ones, and both intentional and accidental breaches.

222 “2024 Data Breach Investigations Report: Healthcare Snapshot,” Verizon Business, p. 12 (May 1, 2024) (The report describes misdelivery as sending information to the wrong recipient, whether by electronic or physical means), https://www.verizon.com/business/resources/reports/dbir/2024/industries-intro/healthcare-data-breaches/.

223 Press release, “HHS' Office for Civil Rights Settles Malicious Insider Cybersecurity Investigation for $4.75 Million,” Office for Civil Rights, U.S. Department of Health and Human Services (Feb. 6, 2024), https://www.hhs.gov/about/news/2024/02/06/hhs-office-civil-rights-settles-malicious-insider-cybersecurity-investigation.html

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

225 “Remediation and Guidance Hub: Falcon Content Update for Windows Hosts,” CrowdStrike, https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/.

226 See “Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events,” NIST Special Publication 1800-26A, National Institute of Standards and Technology, U.S. Department of Commerce, p. 1 (Dec. 2020), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-26.pdf.

227 “Likely eCrime Actor Uses Filenames Capitalizing on July 19, 2024, Falcon Sensor Content Issues in Operation Targeting LATAM-Based CrowdStrike Customers,” CrowdStrike Blog (July 20, 2024), https://www.crowdstrike.com/blog/likely-ecrime-actor-capitalizing-on-falcon-sensor-issues/.

C

ent of Commerce, p. 1 (Dec. 2020), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-26.pdf.

227 “Likely eCrime Actor Uses Filenames Capitalizing on July 19, 2024, Falcon Sensor Content Issues in Operation Targeting LATAM-Based CrowdStrike Customers,” CrowdStrike Blog (July 20, 2024), https://www.crowdstrike.com/blog/likely-ecrime-actor-capitalizing-on-falcon-sensor-issues/.

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.

228 Letter from NCVHS Chair Jacki Monson (2023), supra note 123, p

port on Improving Cybersecurity In The Health Care Industry,” supra note 117, p. 2.

231 “2021 HIMSS Healthcare Cybersecurity Survey,” Healthcare Information and Management Systems Society, p. 18 (Jan. 28, 2022), https://www.himss.org/sites/hde/files/media/file/2022/01/28/2021_himss_cybersecurity_survey.pdf.

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

232 “Muddling through cybersecurity: Insights from the U.S. healthcare industry,” supra note 116, p. 543.

233 Id. at 542.

234 See 68 FR 8334, 8352 (Feb. 20, 2003)

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

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

237 68 FR 8334, 8343 (Feb. 20, 2003).

238 45 CFR 164.308(a)(1)(ii)(A).

239 45 CFR 164.308(a)(1)(ii)(B); “2016-2017 HIPAA Audits Industry Report,” supra note 121, p. 4.

240 “2016-2017 HIPAA Audits Industry Report,” supra note 121, p. 4.

241 Id. at 11.

242 Id. at 27.

243 Id. at 30.

244 Id. at 27 and 30.

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

243 Id. at 30.

244 Id. at 27 and 30.

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

245 See “OCR News Releases & Bulletins,” Office for Civil Rights, U.S. Department of Health and Human Services, https://www.hhs.gov/ocr/newsroom/index.html.

246 See Resolution Agreement, “Doctors' Management Services, Inc.,” Office for Civil Rights, U.S. Department of Health and Human Services (Oct. 31, 2023), https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/dms-ra-cap/index.html; Press Release, “HHS' Office for Civil Rights Settles Ransomware Cyber-Attack Investigation,” Office for Civil Rights, U.S. Department of Health and Human Services (Oct. 31, 2023), https://www.hhs.gov/about/news/2023/10/31/hhs-office-civil-rights-settles-ransomware-cyber-attack-investigation.html; see also “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,” supra note 10.

247 “HHS' Office for Civil Rights Settles Ransomware Cyber-Attack Investigation,” supra note 246

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

measures that are reasonable and appropriate for their circumstances.

254 RS.MA, “The NIST Cybersecurity Framework (CSF) 2.0,” supra note 15.

255 PR.IP-9, “Framework for Improving Critical Infrastructure Cybersecurity,” supra note 250.

256 45 CFR 164.304 (definition of “Security incident”). The definition of security incident includes both attempted and successful incidents. A successful incident is one in which a threat actor is able to, without authorization, access, use, disclose, modify, or destroy information or interfere with system operations in an information system.

257 See, e.g., “Montefiore Medical Center,” supra note 248.

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

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.

258 University of Texas M.D. Anderson Cancer Center v. U.S. Department of Health and Human Services, 985 F.3d 472, 478 (5th Cir. 2021).

259 Id.

260 Id.

Several technical safeguards currently require regulated entities to implement a “mechanism” as part of complying with the associated standard

regulated entity's enterprise to ensure the confidentiality, integrity, and availability of ePHI.

258 University of Texas M.D. Anderson Cancer Center v. U.S. Department of Health and Human Services, 985 F.3d 472, 478 (5th Cir. 2021).

259 Id.

260 Id.

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

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

262 68 FR 8334, 8336 (Feb. 20, 2003).

263 42 U.S.C. 17931(a); 78 FR 5566 (Jan. 25, 2013).

264 78 FR 5566 (Jan. 25, 2013).

265 Id. at 5591.

266 See 68 FR 8334, 8341 (Feb. 20, 2003).

267 Id. at 8344.

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

. 4 (“[M]ost covered entities failed to meet the requirements for other selected provisions in the audit, such as adequately safeguarding protected health information (PHI) [. . .] OCR also found that most covered entities and business associates failed to implement the HIPAA Security Rule requirements for risk analysis and risk management.”); “Enforcement Highlights,” Office for Civil Rights, U.S. Department of Health and Human Services, https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/data/enforcement-highlights/index.html.

269 See, e.g., “Montefiore Medical Center,” supra note 248; “Doctors' Management Services, Inc.,” supra note 246.

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

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:

270 Letter from NCVHS Chair Jacki Monson (2023), supra note 123, p. 2 (detailing the inquiry undertaken by NCVHS into the scope and breadth of security risks and how to best address those challenges).

271 Id.

272 See 42 U.S.C. 1320d-1(f).

273 See Letter from NCVHS Chair Jacki Monson (2022), supra note 123; Letter from NCVHS Chair Jacki Monson (2023), supra note 123.

274 See Letter from NCVHS Chair Jacki Monson (2022), supra note 123, p. 4 (citing a survey performed by a College of Healthcare Information Management Executives (CHIME) as explained at Jill McKeon, “32% of Healthcare Organizations Have a Comprehensive Security Program,” Health IT Security (Nov. 22, 2021), https://healthitsecurity.com/news/32-of-healthcare-organizations-have-a-comprehensive-securityprogram ).

• 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

275 See Letter from NCVHS Chair Jacki Monson (2022), supra note 123, p. 4; see also Letter from NCVHS Chair Jacki Monson (2023), supra note 123, Appendix p. 1

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

285 See proposed 45 CFR 164.306(b)(2)(v).

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.

286 68 FR 8334, 8336 (Feb. 20, 2003).

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

t the security of ePHI and lower the costs associated with breaches and other incidents.

287 Id. at 8346.

288 Id. At that time, the Security Rule applied directly only to covered entities. As discussed above, Congress later extended the application of the Security Rule directly to business associates.

289 68 FR 8334, 8343 (Feb. 20, 2003).

290 Id.

291 78 FR 5566, 5589 (Jan. 25, 2013).

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

292 42 U.S.C. 1320d-2(d)(1)(A)(v).

293 See “Why Health Care is Harder to Access in Rural America,” U.S. Government Accountability Office (May 16, 2023) (When local hospitals close in rural areas, residents have to travel more than 20 miles further to receive common health care and 40 miles further to receive less common health care, such as substance use disorder treatment

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

h 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

306 See, e.g., “Fact Sheet: Biden-Harris Administration Bolsters Protections for Americans' Access to Healthcare Through Strengthening Cybersecurity,” The White House (June 10, 2024), https://www.whitehouse.gov/briefing-room/statements-releases/2024/06/10/fact-sheet-biden-harris-administration-bolsters-protections-for-americans-access-to-healthcare-through-strengthening-cybersecurity/; “How Do Ransomware Attacks Impact Rural Hospitals?,” National Institute for Health Care Management Foundation, p. 1 (2024), https://nihcm.org/assets/articles/FINAL-NIHCM-RI-Hannah-Neprash_2024-08-01-132728_ushq.pdf.

307 “How Do Ransomware Attacks Impact Rural Hospitals?” supra note 306, p. 2.

308 Id.

309 Id.

310 Kevin Collier, “An Illinois hospital is the first health care facility to link its closing to a ransomware attack,” NBC News (June 12, 2023), https://www.nbcnews.com/tech/security/illinois-hospital-links-closure-ransomware-attack-rcna85983.

311 Id

I-Hannah-Neprash_2024-08-01-132728_ushq.pdf.

307 “How Do Ransomware Attacks Impact Rural Hospitals?” supra note 306, p. 2.

308 Id.

309 Id.

310 Kevin Collier, “An Illinois hospital is the first health care facility to link its closing to a ransomware attack,” NBC News (June 12, 2023), https://www.nbcnews.com/tech/security/illinois-hospital-links-closure-ransomware-attack-rcna85983.

311 Id.

312 “Fact Sheet: Biden-Harris Administration Bolsters Protections for Americans' Access to Healthcare Through Strengthening Cybersecurity,” supra note 306.

313 See, e.g., “Free Cybersecurity Services and Tools,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/resources-tools/resources/free-cybersecurity-services-and-tools; “Cyber Hygiene Services,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/cyber-hygiene-services; “Cybersecurity Resources for High-Risk Communities,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/audiences/high-risk-communities/cybersecurity-resources-high-risk-communities.

314 See, e.g., 45 CFR 164.306.

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

IPAA, 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

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

315 See sec. 261 of Pub. L. 104-191, 110 Stat. 2021 (Aug. 21, 1996), as amended by sec. 1104(a) of Pub. L. 111-148, 124 Stat. 146 (Mar. 23, 2010) (codified at 42 U.S.C. 1320d note).

316 Id.

E

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

324 63 FR 43242, 43249 (Aug. 12, 1998); 68 FR 8334, 8341 (Feb. 20, 2003).

325 78 FR 5566, 5589-91, 5693-95 (Jan. 25, 2013).

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

326 63 FR 43249 (Aug. 12, 1998); 68 FR 8341 (Feb. 20, 2003).

327 42 U.S.C. 1320d-2(d)(1)(A).

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

326 63 FR 43249 (Aug. 12, 1998); 68 FR 8341 (Feb. 20, 2003).

327 42 U.S.C. 1320d-2(d)(1)(A).

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.

328 “ANSI/NIST-ITL Standard,” National Institute of Standards and Technology, U.S. Department of Commerce (Feb. 3, 2023), https://www.nist.gov/programs-projects/ansinist-itl-standard

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.

334 45 CFR 160.103 (definition of “Electronic media”).

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

335 78 FR 5566 (Jan. 25, 2013).

336 Id. at 5576.

337 Id

, 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

335 78 FR 5566 (Jan. 25, 2013).

336 Id. at 5576.

337 Id.

338 Id.

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

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.

339 A standard telephone line, often described as a traditional landline, uses circuit-switched voice communication service technologies through the Public Switched Telephone Network. The information transmitted through such traditional telephones is not electronic.

340 VoIP technologies convert audio into a digital signal that is then transmitted over the internet

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

342 See “NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0,” National Institute of Standards and Technology, U.S. Department of Commerce, p. 29 (Jan. 16, 2020) (see definition of “data processing”), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf.

343 See Maithilee Joshi, et al., “Delegated Authorization Framework for EHR Services Using Attribute-Based Encryption,” IEEE Transactions on Services Computing, Volume 14, No. 6, p. 1 (2021) (discussing that health care providers are increasingly using Cloud-based EHR services to manage ePHI, which increases the possibility of attacks on ePHI), https://ebiquity.umbc.edu/get/a/publication/1126.pdf; see also “Security Standards: Technical Safeguards,” HIPAA Security Series, Office for Civil Rights, U.S. Department of Health and Human Services, (May 2005, revised Mar. 2007) (The goal of encryption is to protect ePHI from being accessed and viewed by unauthorized users.), https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/techsafeguards.pdf?language=es.

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

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

350 45 CFR 164.304 (definition of “Administrative safeguards”).

351 45 CFR 164.304 (definitions of “Administrative safeguards,” “Physical safeguards,” and “Technical safeguards”).

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

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.

352 See also Special Publication 800-82r3, Guide to Operational Technology Security, National Institute of Standards and Technology, section 6.2.1, p. 97, Identity Management and Access Control (PR.AC) (discussing the need of organizations to apply authentication controls for users, devices, and processes within the technology environment) (September 2023).

b

o compromise the security of ePHI.

352 See also Special Publication 800-82r3, Guide to Operational Technology Security, National Institute of Standards and Technology, section 6.2.1, p. 97, Identity Management and Access Control (PR.AC) (discussing the need of organizations to apply authentication controls for users, devices, and processes within the technology environment) (September 2023).

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,

have access on demand to ePHI to carry out their functions.

b

mation 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,

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

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

353 While the Department also regulates “adoption and meaningful use of certified EHR technology,” such as the actions of the end-user with respect to having and meaningfully using certified health IT to meet certain requirements, such as those requirements for the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS) (sections 1848(q)(2)(B)(iv) and 1848(o)(2) of the SSA), the definitions proposed in this NPRM would apply only to regulated entities' compliance with the Security Rule.

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

356 See proposed 45 CFR 164.308(b)(1)(i) and (ii) and (b)(2)(ii).

357 See proposed 45 CFR 164.312(a)(1).

358 See proposed 45 CFR 164.312(a)(2)(iv).

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

ll 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

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

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

359 See 45 CFR 164.310(a)(1).

360 See 45 CFR 164.312(a)(1).

361 45 CFR 164.304 (definition of “Physical safeguards”).

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

tems 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

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

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

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.

376 See 45 CFR 164.304 (definition of “Facility”).

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.

377 45 CFR 164.306.

b

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

377 45 CFR 164.306.

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

supra note 258, p. 478.

389 For example, in the 2003 Final Rule, we explained that in developing technical safeguards, the Department proposed technical security services requirements and specific technical security mechanisms with implementation specifications without carving out or limiting these items to policies and procedures about the requirements. See 68 FR 8334, 8354 (Feb. 20, 2003).

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

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

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

390 45 CFR 164.304 (definition of “Technical safeguards”).

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

fter 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

393 See 45 CFR 160.502 of the 2003 interim final rule, 68 FR 18895, 18898 (Apr. 17, 2003).

394 45 CFR 160.103 (definition of “Person”).

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.

395 45 CFR 164.304 (definition of “User”).

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,

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

396 See “Defending Against Common Cyber-Attacks,” Cybersecurity Newsletter, Office for Civil Rights, U.S. Department of Health and Human

Services (Mar

ed 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

396 See “Defending Against Common Cyber-Attacks,” Cybersecurity Newsletter, Office for Civil Rights, U.S. Department of Health and Human

Services (Mar. 2022), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-first-quarter-2022/index.html.

397 Id.

398 Id.; The National Vulnerability Database is the U.S. government repository of standards-based vulnerability management data. See “National Vulnerability Database,” National Institute of Standards and Technology, U.S. Department of Commerce, https://nvd.nist.gov.

399 “Known Exploited Vulnerabilities Catalog,” Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

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

400 See NIST definition of “vulnerability,” Glossary, Computer Security Resource Center, National Institute of Standards and Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/vulnerability.

401 Proposed 45 CFR 164.308(a)(2)(ii)(A)( 7 ).

402 Proposed 45 CFR 164.308(a)(4)(i).

403 Proposed 45 CFR 164.312(h)(1).

22. Clarifying the Definition of “Workstation”

a

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

412 See University of Texas M.D. Anderson Cancer Center, supra note 258, p. 478.

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

Department of Health and Human Services ( Aug. 2024), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-august-2024/index.html.

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

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

417 Letter from NCVHS Chair Jacki Monson (2022), supra note 123, p. 2.

418 Id. at Appendix p. 4.

419 Id.

420 Id at 5.

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

ons 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

422 68 FR 8334, 8341 (Feb. 20, 2003); see also Jennifer Cawthra, et al., “Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events,” NIST Special Publication 1800-25A, National Institute of Standards and Technology, U.S. Department of Commerce, p. 1 (Dec. 2020) (“The CIA triad represents the three pillars of information security: confidentiality, integrity, and availability.”), https://www.nccoe.nist.gov/publication/1800-25/VolA/index.html.

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

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

423 42 U.S.C. 1320d-2(d)(2)(A) and (C).

424 Section 164.530(c) includes the Privacy Rule standard and implementation specification for safeguarding PHI. It requires covered entities to have in place appropriate administrative, physical, and technical safeguards to protect the privacy of PHI. Additionally, it requires covered entities to reasonably safeguard PHI from intentional or unintentional uses or disclosures that violate the Privacy Rule, and to limit incidental uses or disclosures made pursuant to a permissible or required use or disclosure of PHI.

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

y, 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

425 42 U.S.C. 1320d-2(d).

The Department also proposes to add a new element to the list of factors that regulated entities must take into account

This text is long and has been trimmed here. Open the source document for the complete record.