[Federal Register Volume 90, Number 3 (Monday, January 6, 2025)]
[Proposed Rules]
[Pages 898-1022]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-30983]
[[Page 897]]
Vol. 90
Monday,
No. 3
January 6, 2025
Part III
Department of Health and Human Services
-----------------------------------------------------------------------
45 CFR Parts 160 and 164
HIPAA Security Rule To Strengthen the Cybersecurity of Electronic
Protected Health Information; Proposed Rule
Federal Register / Vol. 90 , No. 3 / Monday, January 6, 2025 /
Proposed Rules
[[Page 898]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 160 and 164
RIN 0945-AA22
HIPAA Security Rule To Strengthen the Cybersecurity of Electronic
Protected Health Information
AGENCY: Office for Civil Rights (OCR), Office of the Secretary,
Department of Health and Human Services.
ACTION: Notice of proposed rulemaking; notice of Tribal consultation.
-----------------------------------------------------------------------
SUMMARY: The Department of Health and Human Services (HHS or
``Department'') is issuing this notice of proposed rulemaking (NPRM) to
solicit comment on its proposal to modify the Security Standards for
the Protection of Electronic Protected Health Information (``Security
Rule'') under the Health Insurance Portability and Accountability Act
of 1996 (HIPAA) and the Health Information Technology for Economic and
Clinical Health Act of 2009 (HITECH Act). The proposed modifications
would revise existing standards to better protect the confidentiality,
integrity, and availability of electronic protected health information
(ePHI). The proposals in this NPRM would increase the cybersecurity for
ePHI by revising the Security Rule to address: changes in the
environment in which health care is provided; significant increases in
breaches and cyberattacks; common deficiencies the Office for Civil
Rights has observed in investigations into Security Rule compliance by
covered entities and their business associates (collectively,
``regulated entities''); other cybersecurity guidelines, best
practices, methodologies, procedures, and processes; and court
decisions that affect enforcement of the Security Rule.
DATES:
Comments: Submit comments on or before March 7, 2025.
Meeting: Pursuant to Executive Order 13175, Consultation and
Coordination with Indian Tribal Governments, the Department of Health
and Human Services' Tribal Consultation Policy, and the Department's
Plan for Implementing Executive Order 13175, the Office for Civil
Rights solicits input from Tribal officials as the Department develops
the modifications to the HIPAA Security Rule at 45 CFR part 160 and
subparts A and C of 45 CFR part 164. The Tribal consultation meeting
will be held on February 6, 2025, at 2 p.m. to 3:30 p.m. eastern time.
ADDRESSES: You may submit comments, identified by RIN Number 0945-AA22,
by any of the following methods. Please do not submit duplicate
comments.
Federal eRulemaking Portal: You may submit electronic
comments at https://www.regulations.gov by searching for the Docket ID
number HHS-OCR-0945-AA22. Follow the instructions at https://www.regulations.gov for submitting electronic comments. Attachments
should be in Microsoft Word or Portable Document Format (PDF).
Regular, Express, or Overnight Mail: You may mail written
comments to the following address only: U.S. Department of Health and
Human Services, Office for Civil Rights, Attention: HIPAA Security Rule
NPRM, Hubert H. Humphrey Building, Room 509F, 200 Independence Avenue
SW, Washington, DC 20201. Please allow sufficient time for mailed
comments to be timely received in the event of delivery or security
delays.
Please note that comments submitted by fax or email and those
submitted after the comment period will not be accepted.
Inspection of Public Comments: All comments received by the
accepted methods and due date specified above may be posted without
change to content to https://www.regulations.gov, which may include
personal information provided about the commenter, and such posting may
occur after the closing of the comment period. However, the Department
may redact certain non-substantive content from comments or attachments
to comments before posting, including: threats, hate speech, profanity,
sensitive health information, graphic images, promotional materials,
copyrighted materials, or individually identifiable information about a
third-party individual other than the commenter. In addition, comments
or material designated as confidential or not to be disclosed to the
public will not be accepted. Comments may be redacted or rejected as
described above without notice to the commenter, and the Department
will not consider in rulemaking any redacted or rejected content that
would not be made available to the public as part of the administrative
record.
Docket: For complete access to background documents, the plain-
language summary of the proposed rule of not more than 100 words in
length required by the Providing Accountability Through Transparency
Act of 2023, or posted comments, go to https://www.regulations.gov and
search for Docket ID number HHS-OCR-0945-AA22.
Tribal consultation meeting: To participate in the Tribal
consultation meeting, you must register in advance at https://hhsgov.zoomgov.com/meeting/register/vJItdOyhrjgoHxJWMDxozrxT98yXyCO3lks.
FOR FURTHER INFORMATION CONTACT: Marissa Gordon-Nguyen at (202) 240-
3110 or (800) 537-7697 (TDD), or by email at [email protected].
SUPPLEMENTARY INFORMATION: The discussion below includes an Executive
Summary, a description of relevant statutory and regulatory authority
and history, the justification for this proposed regulation, a section-
by-section description of the proposed modifications, and a regulatory
impact analysis and other required regulatory analyses. The Department
solicits public comment on all aspects of the proposed rule. The
Department requests that persons commenting on the provisions of the
proposed rule label their discussion of any particular provision or
topic with a citation to the section of the proposed rule being
addressed and identify the particular request for comment being
addressed, if applicable.
Table of Contents
I. Executive Summary
A. Overview
B. Applicability
C. Table of Abbreviations/Commonly Used Acronyms in This
Document
II. Statutory Authority and Regulatory History
A. Statutory Authority and History
1. Health Insurance Portability and Accountability Act of 1996
(HIPAA)
2. Health Information Technology for Economic and Clinical
Health (HITECH) Act
B. Regulatory History
1. 1998 Security Rule Notice of Proposed Rulemaking
2. 2003 Final Rule
3. 2009 Delegation of Authority
4. 2013 Omnibus Rulemaking
III. Justification for This Proposed Rulemaking
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
B. The Health Care Environment Has Changed Since the Security
Rule Was Last Revised and Will Continue To Evolve
C. Regulated Entities' Compliance With the Requirements of the
Security Rule Is Inconsistent
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
[[Page 899]]
Safeguards Would Evolve To Address Changes in the Health Care
Environment
2. NCVHS Believes That the Security Standards Evolve To Address
Changes in the Health Care Environment
3. A Strengthened Security Rule Would Continue To Be Flexible
and Scalable While Providing Regulated Entities With Greater Clarity
4. Small and Rural Health Care Providers Must Implement Strong
Security Measures To Provide Efficient and Effective Health Care
5. A Strengthened Security Rule Is Critical to an Efficient and
Effective Health Care System
E. The Secretary Must Develop Standards for the Security of ePHI
Because None Have Been Developed by an ANSI-Accredited Standard
Setting Organization
IV. Section-by-Section Description of the Proposed Amendments to the
Security 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. Section 164.316--Documentation Requirements
1. Current Provisions
2. Issues To Address
3. Proposals
4. Request for Comment
I. Section 164.318--Transition Provisions
1. Current Provisions and Issues To Address
2. Proposal
3. Request for Comment
J. Section 164.320--Severability
K. New and Emerging Technologies Request for Information
1. Quantum Computing
2. Artificial Intelligence (AI)
3. Virtual and Augmented Reality (VR and AR)
4. Request for Comment
V. Regulatory Impact Analysis
A. Executive Order 12866 and Related Executive Orders on
Regulatory Review
1. Summary of Costs and Benefits
2. Baseline Conditions
3. Costs of the Proposed Rule
4. Benefits of the Proposed Rule
5. Comparison of Benefits and Costs
B. Regulatory Alternatives to the Proposed Rule
C. Regulatory Flexibility Act--Small Entity Analysis
D. Executive Order 13132--Federalism
E. Assessment of Federal Regulation and Policies on Families
F. Paperwork Reduction Act of 1995
1. Explanation of Estimated Annualized Burden Hours
I. Executive Summary
A. Overview
In this notice of proposed rulemaking (NPRM), the Department of
Health and Human Services (HHS or ``Department'') proposes
modifications to the Security Standards for the Protection of
Electronic Protected Health Information (``Security Rule''), issued
pursuant to section 262(a) of the Administrative Simplification
provisions of title II, subtitle F, of the Health Insurance Portability
and Accountability Act of 1996 (HIPAA).\1\ The Security Rule \2\ is one
of several rules, collectively known as the HIPAA Rules,\3\ that
protect the privacy and security of individuals' protected health
information \4\ (PHI), which is individually identifiable health
information \5\ (IIHI) transmitted by or maintained in electronic media
or any other form or medium, with certain exceptions.\6\ The Security
Rule applies only to electronic PHI (ePHI), which is IIHI that is
transmitted by or maintained in electronic media.\7\
---------------------------------------------------------------------------
\1\ Subtitle F of title II of HIPAA (Pub. L. 104-191, 110 Stat.
1936 (Aug. 21, 1996)) added a new part C to title XI of the Social
Security Act of 1935 (SSA), Public Law 74-271, 49 Stat. 620 (Aug.
14, 1935), (see sections 1171-1179 of the SSA (codified at 42 U.S.C.
1320d-1320d-8)), as well as promulgating section 264 of HIPAA
(codified at 42 U.S.C. 1320d-2 note), which authorizes the Secretary
to promulgate regulations with respect to the privacy of
individually identifiable health information. The Privacy Rule has
subsequently been amended pursuant to the Genetic Information
Nondiscrimination Act of 2008, title I, section 105, Public Law 110-
233, 122 Stat. 881 (May 21, 2008) (codified at 42 U.S.C. 2000ff),
and the Health Information Technology for Economic and Clinical
Health (HITECH) Act of 2009, Public Law 111-5, 123 Stat. 226 (Feb.
17, 2009) (codified at 42 U.S.C. 139w-4(0)(2)).
\2\ 45 CFR part 160 subparts A and C of 45 CFR part 164. For a
history of the Security Rule, see section II.B, ``Regulatory
History.''
\3\ See also the HIPAA Privacy Rule, 45 CFR part 160 and
subparts A and E of 45 CFR part 164; HIPAA Breach Notification Rule,
45 CFR part 164, subpart D; and the HIPAA Enforcement Rule, 45 CFR
part 160, subparts C through E.
\4\ 45 CFR 160.103 (definition of ``Protected health
information'').
\5\ 45 CFR 160.103 (definition of ``Individually identifiable
health information'').
\6\ At times throughout this NPRM, the Department uses the terms
``health information'' or ``individuals' health information'' to
refer generically to health information pertaining to an individual
or individuals. In contrast, the Department's use of the term
``IIHI'' refers to a category of health information defined in
HIPAA, and ``PHI'' is used to refer specifically to a category of
IIHI that is defined by and subject to the requirements of the HIPAA
Rules. The HIPAA Rules exclude from the definition of PHI: IIHI in
employment records held by a covered entity in its role as employer;
IIHI in education records and certain treatment records covered by
the Family Educational Rights and Privacy Act (codified at 20 U.S.C.
1232g); and IIHI regarding a person who has been deceased for more
than 50 years. 45 CFR 160.103 (definition of ``Protected health
information'').
\7\ 45 CFR 160.103 (definition of ``Electronic protected health
information'').
---------------------------------------------------------------------------
The Security Rule was initially published in 2003 and most recently
revised in 2013.\8\ Since its publication, there have been significant
changes to the environment in which health care is provided and how the
health care industry operates. Today, cybersecurity is a concern that
touches nearly every facet of modern health care, certainly more than
it did in 2003 or even 2013.
[[Page 900]]
Almost every stage of modern health care relies on stable and secure
computer and network technologies, including, but not limited to, the
following: appointment scheduling, prescription orders, telehealth
visits, medical devices, patient records, medical and pharmacy claims
submissions and billing, insurance coverage verifications, payroll,
facilities access and management, internal and external communications,
and clinician resources. These tools and technologies are an integral
part of the modern health care system, but they also present
opportunities for bad actors to cause harm through hacking, ransomware,
and other means. Covered entities and business associates
(collectively, ``regulated entities'') may also experience malfunctions
and inadvertent errors that threaten the confidentiality, integrity, or
availability of ePHI. Thus, cyberattacks, malfunctions, and inadvertent
errors can negatively affect the provision of health care, as well as
the efficiency and effectiveness of the 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. 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. 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. Department of Health and Human
Services and the Healthcare & Public Health Sector Coordinating
Council (2023), https://405d.hhs.gov/Documents/HICP-Main-508.pdf.
\17\ ``Start with Security: A Guide for Business,'' Federal
Trade Commission (Aug. 2023), https://www.ftc.gov/system/files/ftc_gov/pdf/920a_start_with_security_en_aug2023_508_final_0.pdf.
\18\ ``Cybersecurity Performance Goals,'' U.S. Department of
Health and Human Services (Jan. 2024), https://hphcyber.hhs.gov/performance-goals.html.
---------------------------------------------------------------------------
Under its statutory authority to administer and enforce the HIPAA
Rules, the Department modifies the HIPAA Rules as needed, but does not
modify a standard or implementation specification more than once every
12 months.\19\ The Department makes the determination that such
modifications may be needed using information it receives on an ongoing
basis--from the Department's Federal advisory committee on HIPAA, the
public, regulated entities, media reports, and its own analysis of the
state of privacy and security for IIHI. As referenced above, and
discussed in greater detail below, while the Department believes that
the Security Rule generally continues to accomplish the goals of
HIPAA,\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.
[[Page 901]]
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).
---------------------------------------------------------------------------
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). Under the existing Security Rule,
a regulated entity must assess whether encryption is a reasonable and
appropriate safeguard in its environment, when analyzed with reference
to its likely contribution to protecting ePHI, and implement encryption
if reasonable and appropriate.\24\ If encryption is not reasonable and
appropriate, a regulated entity must document why it would not be
reasonable and appropriate for it to implement the safeguard and must
implement an equivalent alternative measure if reasonable and
appropriate.\25\ As discussed in greater detail below, encryption is
built into most software today, and where it is not, there are
affordable and easily implemented solutions that can encrypt sensitive
information. Thus, it generally would be reasonable and appropriate for
regulated entities to implement a mechanism to encrypt ePHI, and
regulated entities should already have done so in most circumstances.
By expressly requiring regulated entities to encrypt ePHI, with limited
exceptions, the Department's proposal would reflect our expectations in
the current cybersecurity environment and 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.
ASTP/ONC.......................... Assistant Secretary for Technology
Policy and Office of the National
Coordinator for Health Information
Technology.
CISA.............................. Cybersecurity & Infrastructure
Security Agency.
CMS............................... Centers for Medicare & Medicaid
Services.
CPG............................... Cybersecurity Performance Goal.
Department or HHS................. Department of Health and Human
Services.
EHR............................... Electronic Health Record.
E.O............................... Executive Order.
ePHI.............................. Electronic Protected Health
Information.
FDA............................... Food & Drug Administration.
FISMA............................. Federal Information Security
Modernization Act.
FTC............................... Federal Trade Commission.
Health IT......................... Health Information Technology.
[[Page 902]]
HIPAA............................. Health Insurance Portability and
Accountability Act of 1996.
HITECH Act........................ Health Information Technology for
Economic and Clinical Health Act of
2009.
ICR............................... Information Collection Request.
IIHI.............................. Individually Identifiable Health
Information.
IT................................ Information Technology.
MFA............................... Multi-factor Authentication.
NAICS............................. North American Industry
Classification System.
NCVHS............................. National Committee on Vital and
Health Statistics.
NIST.............................. National Institute of Standards and
Technology.
NPRM.............................. Notice of Proposed Rulemaking.
OCR............................... Office for Civil Rights.
OMB............................... Office of Management and Budget.
ONC............................... Office of the National Coordinator
for Health Information Technology.
PHI............................... Protected Health Information.
PRA............................... Paperwork Reduction Act of 1995.
PSAO.............................. Pharmacy Services Administration
Organizations.
RFA............................... Regulatory Flexibility Act.
RIA............................... Regulatory Impact Analysis.
SBA............................... Small Business Administration.
SRMA.............................. Sector Risk Management Agency.
SSA............................... Social Security Act of 1935.
UMRA.............................. Unfunded Mandates Reform Act of
1995.
VR................................ Virtual Reality.
------------------------------------------------------------------------
II. Statutory Authority and Regulatory History
A. Statutory Authority and History
1. Health Insurance Portability and Accountability Act of 1996 (HIPAA)
In 1996, Congress enacted HIPAA \28\ to reform the health care
delivery system to ``improve portability and continuity of health
insurance coverage in the group and individual markets'' \29\ and ``to
simplify the administration of health insurance.'' \30\ Through
subtitle F of HIPAA, Congress amended title XI of the Social Security
Act of 1935 (SSA) by adding part C, entitled ``Administrative
Simplification.'' \31\ A primary purpose of part C is to improve the
Medicare and Medicaid programs and ``the efficiency and effectiveness
of the health care system, by encouraging the development of a health
information system through the establishment of uniform standards and
requirements for the electronic transmission of certain health
information.'' \32\
---------------------------------------------------------------------------
\28\ Public Law 104-191, 110 Stat. 1936 (Aug. 21, 1996)
(codified at 42 U.S.C. 201 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. 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).
---------------------------------------------------------------------------
HIPAA required the Secretary to adopt uniform standards ``to enable
health information to be exchanged electronically.'' \41\ Congress also
directed the Secretary to, among other things, adopt standards for the
security of IIHI.\42\ The statute also directed the Secretary to adopt
initial security standards within 18 months of its
[[Page 903]]
enactment.\43\ In adopting security standards for health information,
HIPAA requires the Secretary to consider all of the following: \44\
---------------------------------------------------------------------------
\41\ Sec. 262(a) of Public Law 104-191, 110 Stat. 2024, adding
sec. 1173(a) (codified at 42 U.S.C. 1320d-2(a)(1)).
\42\ Sec. 262(a) of Public Law 104-191, 110 Stat. 2025, adding
sec. 1173(d) (codified at 42 U.S.C. 1320d-2(d)).
\43\ Sec. 262(a) of Public Law 104-191, 110 Stat. 2026, adding
sec. 1174(a) (codified at 42 U.S.C. 1320d-3(a)).
\44\ Sec. 262(a) of Public Law 104-191, 110 Stat. 2025, adding
sec. 1173(d)(1) (codified at 42 U.S.C. 1320d-2(d)(1)).
---------------------------------------------------------------------------
The technical capabilities of record systems used to
maintain health information.
The costs of security measures.
Training for persons who have access to health
information.
The value of audit trails in computerized record systems.
The needs and capabilities of small health care providers
and rural health care providers.\45\
---------------------------------------------------------------------------
\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. 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. 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. accompanying S. 336, 111th
Cong., at 59 (2009).
\57\ Sec. 13401 of Public Law 111-5, 123 Stat. 260 (codified at
42 U.S.C. 17931).
\58\ Sec. 13401(a) of Public Law 111-5, 123 Stat. 260 (codified
at 42 U.S.C. 17931).
\59\ Sec. 13401(c) of Public Law 111-5, 123 Stat. 260 (codified
at 42 U.S.C. 17931).
---------------------------------------------------------------------------
In enacting the HITECH Act, Congress affirmed that the existing
HIPAA Rules were to remain in effect to the extent that they are
consistent with the HITECH Act and directed the Secretary to revise the
HIPAA Rules as necessary for consistency with the HITECH Act.\60\
Congress confirmed that the new law was not intended to have any effect
on authorities already granted under HIPAA to the Department, including
part C of title XI of the SSA.\61\ Thus, Congress affirmed the
Secretary's ongoing rulemaking authority to modify the Security Rule's
standards and implementation specifications as often as every 12 months
when appropriate, including to strengthen security protections for
IIHI.
---------------------------------------------------------------------------
\60\ Sec. 13421(b) of the HITECH Act (codified at 42 U.S.C.
17951).
\61\ Sec. 3009(a)(1)(A) of the PHSA, as added by sec. 13101 of
the HITECH Act (codified at 42 U.S.C. 300jj-19(a)(1)).
---------------------------------------------------------------------------
In 2021, the HITECH Act was amended to require the HHS Secretary to
further encourage regulated entities to bolster their cybersecurity
practices.\62\ The amendment requires the Department to consider
certain recognized security practices of regulated entities when making
determinations relating to certain Security Rule compliance and
enforcement activities.\63\
---------------------------------------------------------------------------
\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
[[Page 904]]
protect ePHI.\64\ Specifically, regulated entities must ensure the
confidentiality, integrity, and availability of all ePHI they create,
receive, maintain, or transmit; \65\ protect against reasonably
anticipated threats or hazards to the security or integrity of the
information \66\ and reasonably anticipated impermissible uses or
disclosures; \67\ and ensure compliance by their workforce.\68\
---------------------------------------------------------------------------
\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.
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.\74\ First, the standard should be
comprehensive and coordinated to address all aspects of security.
Second, it should be scalable, so that it could be effectively
implemented by covered entities of all types and sizes. Third, it
should not be linked to specific technologies, allowing covered
entities the flexibility to make use of future technology
advancements.\75\
---------------------------------------------------------------------------
\73\ Id. at 43249.
\74\ See 68 FR 8334, 8335 (Feb. 20, 2003).
\75\ Id.; see also 63 FR 43242, 43249 (Aug. 12, 1998).
---------------------------------------------------------------------------
The 1998 Proposed Rule included four categories of requirements
that a covered entity would have to address to safeguard the
confidentiality, integrity, and availability of ePHI. They were as
follows:
Administrative procedures.
Physical safeguards.
Technical security services.
Technical mechanisms.
The implementation specifications described some of the
requirements in greater detail, based on our determination regarding
the level of instruction necessary to implement such requirements.\76\
The Department viewed all categories as equally important.\77\
---------------------------------------------------------------------------
\76\ 63 FR 43242, 43250 (Aug. 12, 1998).
\77\ Id.
---------------------------------------------------------------------------
The proposed standard did not address the extent to which a covered
entity should implement the specifications.\78\ Instead, the Department
proposed to require that each covered entity assess its own security
needs and risks and devise, implement, and maintain appropriate
security to address its business requirements. The Department believed
that this approach would leave a significant amount of flexibility for
covered entities and balance the needs of securing health data against
risk with the economic cost of doing so.\79\
---------------------------------------------------------------------------
\78\ Id. at 43249-50.
\79\ Id. at 43250.
---------------------------------------------------------------------------
2. 2003 Final Rule
The Department issued the final Security Rule \80\ on February 20,
2003 (``2003 Final Rule''). In accordance with the Administrative
Simplification provisions of HIPAA, the 2003 Final Rule adopted
standards for the security of ePHI to be implemented by covered
entities.
---------------------------------------------------------------------------
\80\ 45 CFR parts 160 and subparts A and C of 45 CFR part 164;
68 FR 8334 (Feb. 20, 2003).
---------------------------------------------------------------------------
The Department reiterated the purposes and guiding principles it
articulated in the 1998 Proposed Rule and repeated that the protection
of the privacy of information depends in large part on the existence of
security measures to protect that information.\81\ The Department noted
that there were still no standard measures in the health care industry
that address all aspects of the security of ePHI while it is being
stored or during the exchange of that information between entities.\82\
The Department explained that the use of the security standards would
improve the Medicare and Medicaid programs, other Federal health
programs and private health programs, and the effectiveness and
efficiency of the health care industry in general by establishing a
level of protection for ePHI.\83\
---------------------------------------------------------------------------
\81\ 68 FR 8334, 8335, 8371-72 (Feb. 20, 2003).
\82\ Id.
\83\ Id.
---------------------------------------------------------------------------
Provisions of the 2003 Final Rule did not mirror the 1998 Proposed
Rule; rather, the Department finalized only certain changes. The
Department noted, for example, that to maintain consistency with the
use of terms as they appear in the statute and other previously
released HIPAA Rules (i.e., the HIPAA Privacy and Transactions Rules),
it was changing some terminology from the 1998 Proposed Rule, replacing
the terms ``requirement'' with ``standard'' and ``implementation
feature'' with ``implementation specification.'' \84\
---------------------------------------------------------------------------
\84\ Id. at 8335.
---------------------------------------------------------------------------
According to the Department, the comments received in response to
the 1998 Proposed Rule overwhelmingly validated its basic assumptions
that the covered entities were so varied in terms of installed
technology, size, resources, and relative risk, that it would be
impossible to dictate a specific solution or set of solutions that
would be usable by all covered entities.\85\ Similarly, we received
numerous comments expressing the view that the security standards
should not be overly prescriptive because the speed with which
technology is evolving could make specific requirements obsolete and
might in fact deter technological progress. Accordingly, the Department
framed the standards in the 2003 Final Rule in terms that were as
generic as possible and that could generally be met through a variety
of approaches or technologies.\86\ The standards, we
[[Page 905]]
explained, do not allow organizations to make their own rules, only
their own technology choices.\87\
---------------------------------------------------------------------------
\85\ Id.
\86\ Id. at 8336.
\87\ Id. at 8343.
---------------------------------------------------------------------------
We also recognized that entities could minimize risk through their
security practices, but likely could never completely eliminate all
risk. In the preamble to the 2003 Final Rule, the Department
acknowledged that there is no such thing as a totally secure system
that carries no risks to security.\88\ The Department opined that
Congress' intent in the use of the word ``ensure'' in section 1173(d)
of the SSA was to set an exceptionally high goal for the security of
ePHI. However, we also recognized that Congress anticipated that some
trade-offs would be necessary, and that ``ensuring'' protection did not
mean doing so without any regard to the cost.\89\ As such, the
Department explained that we expected a covered entity to protect that
information to the best of its ability.\90\ Thus, a covered entity
would be expected to balance the identifiable risks to and
vulnerabilities of ePHI with the cost of various protective measures,
while also taking into consideration the size, complexity, and
capabilities of the covered entity.\91\
---------------------------------------------------------------------------
\88\ Id. at 8346.
\89\ Id.
\90\ Id.
\91\ Id.
---------------------------------------------------------------------------
In the 2003 Final Rule, the Department introduced the concept of
``addressable'' implementation specifications, which it distinguished
from ``required'' implementation specifications. The goal was to
provide covered entities with even more flexibility.\92\ While none of
the implementation specifications were optional, designating some of
the implementation specifications as addressable provided each covered
entity with the ability to determine whether certain implementation
specifications were reasonable and appropriate safeguards for that
entity, based on its risk analysis, risk mitigation strategy,
previously implemented security measures, and the cost of
implementation.\93\
---------------------------------------------------------------------------
\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).
\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.
The HITECH Act extended the application of the Security Rule's
administrative, physical, and technical safeguards requirements, as
well as the rule's policies and procedures and documentation
requirements, to business associates in the same manner as the
requirements apply to covered entities, making those business
associates civilly and criminally liable for violations of the Security
Rule.\101\ The Department noted that the Security Rule requires a
covered entity to establish business associate agreements that obligate
business associates to implement administrative, physical, and
technical safeguards that reasonably and appropriately protect the
confidentiality, integrity, and availability of the ePHI that they
create, receive, maintain, or transmit on behalf of the covered
entity.\102\ Accordingly, we reasoned that business associates and
subcontractors should already have security practices in place that
comply with the Security Rule, or require only modest improvement to
come into compliance with the Security Rule requirements.\103\ Like the
2003 Final Rule,\104\ the 2013 Omnibus Rule highlighted that the
Security Rule was designed to be technology neutral and scalable and
reiterated that regulated entities have the flexibility to choose
security measures appropriate for their size, resources, and the nature
of the security risks they face.\105\ Accordingly, regulated entities
have the flexibility to choose appropriate security measures
considering their size, capabilities, the costs of the specific
security measures, and the operational impact, enabling them to
reasonably implement the standards of the Security Rule.
---------------------------------------------------------------------------
\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
[[Page 906]]
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. Justification for This Proposed Rulemaking
HIPAA and the HIPAA Rules promote access to high-quality and
effective health care by establishing standards for the security of
ePHI. The standards, when implemented appropriately by regulated
entities, protect the confidentiality, integrity, and availability of
individuals' health information. Such protections promote the
electronic transmission of PHI through a national health information
system. To ensure access to high-quality health care services,
regulated entities must assure their customers (e.g., individuals,
health care providers, and health plans) of the security of the
sensitive and confidential health information the regulated entities
electronically create, receive, maintain, or transmit.
As discussed above, the Security Rule carefully balances the
benefits of safeguarding against security risks with the burdens of
implementing protective measures by permitting regulated entities to
consider several factors, including costs and available technology for
preventing and mitigating security risks,\108\ when determining which
security measures are reasonable and appropriate for protecting the
security of individuals' ePHI.\109\
---------------------------------------------------------------------------
\108\ As technology has evolved and 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.\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.
\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 [. . .]
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.
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
[[Page 907]]
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.
---------------------------------------------------------------------------
\121\ See ``2016-2017 HIPAA Audits Industry Report,'' Office for
Civil Rights, U.S. Department of Health and Human Services (Dec.
2020), https://www.hhs.gov/sites/default/files/hipaa-audits-industry-report.pdf.
---------------------------------------------------------------------------
And the Department is not alone in its concerns. NCVHS serves as
the Department's advisory body for HIPAA.\122\ Given the increase in
cybersecurity incidents affecting the health care sector, NCVHS held a
series of public hearings on cybersecurity to better understand how to
protect ePHI and individuals. In response to those hearings, NCVHS
submitted several recommendations to the Department regarding the
importance of strengthening the Security Rule.\123\ As discussed above,
HIPAA requires the Secretary to rely on NCVHS' recommendations \124\
with respect to standards promulgated under the statute.
---------------------------------------------------------------------------
\122\ See sec. 262 of Public Law 104-191, 110 Stat. 2023 (Aug.
21, 1996) (codified at 42 U.S.C. 1320d-1(f)), added sec. 1172(f) of
the SSA; see also ``About NCVHS,'' National Committee on Vital and
Health Statistics, www.ncvhs.hhs.gov.
\123\ See Letter from NCVHS Chair Jacki Monson to HHS Secretary
Xavier Becerra (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.
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.
---------------------------------------------------------------------------
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.\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
[[Page 908]]
immutable. For example, an individual's date and location of birth and
their health history will not change, even if their address might. In
contrast, an individual's passwords, bank account numbers, and other
financial information can all be changed. Thus, PHI can continue to be
exploited throughout an individual's lifetime, making PHI likely to be
far more valuable than an individual's credit card information.\135\
---------------------------------------------------------------------------
\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.
\132\ ``Report on Improving Cybersecurity In The Health Care
Industry,'' supra note 117, p. 14-15.
\133\ Id.
\134\ ``An Insight into the Current Security Posture of
Healthcare IT: A National Security Concern,'' supra note 130, p. 3.
\135\ See, e.g., Caleb J. Kumar, ``New Dangers in the New World:
Cyber Attacks in the Healthcare Industry,'' Intersect, Volume 10,
No. 3, p. 3 (2017).
---------------------------------------------------------------------------
On the surface, the harms that result from a breach of ePHI or a
cyberattack on a regulated entity's electronic information systems, as
discussed above, are not significantly different than those that would
result from a breach of information in another sector. However, the
reality is, as discussed above, that the implications of such harms are
far greater in the health care sector because of their potential to
adversely affect an individual's health or quality of life, or even to
cost an individual their life.\136\ As stated by the Health Care
Industry Cybersecurity Task Force in its 2017 report on the state of
cybersecurity in health care: ``The health care system cannot deliver
effective and safe care without deeper digital connectivity. If the
health care system is connected, but insecure, this connectivity could
betray patient safety, subjecting them to unnecessary risk and forcing
them to pay unaffordable personal costs.'' \137\ In the event of a
cybersecurity incident, patients' health, including their lives, may be
at risk where such incident creates impediments to the provision of
health care, such as interference with the operations of a critical
medical device, or to the administrative or clinical operations of a
regulated entity, such as preventing the scheduling of appointments or
viewing of an individual's health history.\138\
---------------------------------------------------------------------------
\136\ ``An Insight into the Current Security Posture of
Healthcare IT: A National Security Concern,'' supra note 130, p. 3.
\137\ ``Report on Improving Cybersecurity In The Health Care
Industry,'' supra note 117, p. 2.
\138\ Id. at 18.
---------------------------------------------------------------------------
According to a Cybersecurity & Infrastructure Security Agency
(CISA) statistical analysis of the effects of a hypothetical
cyberattack on a model hospital, a hospital's relative performance will
suffer amidst a cyberattack.\139\ The analysis found that the
hypothetical cyberattack would lead to hospital strain from
inaccessible patient schedules and records, disrupted communication,
and delays in processing and communicating test results in time to
effectively treat individuals.\140\ While the analysis did not find any
deaths directly attributable to the hypothetical attack, it is logical
to conclude that deaths--or at least worsened outcomes--are a
significant risk where there are disruptions in communications, as well
as delays in processing and communicating test results, especially for
emergent or acute medical cases. For example, an inability to access an
individual's pharmacy records could affect the ability of a pharmacist
to identify known interactions between newly prescribed medications and
an existing medication list, potentially leading to an individual's
injury or death. Other studies have similarly found that cyberattacks
can have a substantial effect on access to health care, and potentially
mortality.\141\ In fact, a more recent study found that cyberattacks
had disproportionately negative effects on in-hospital mortality rates
for Black patients who were already admitted to the hospital at the
time of the cyberattack.\142\ A recent survey found that 92 percent of
surveyed health care organizations had experienced a cyberattack in the
past year \143\ and almost three-quarters of the respondents who had
experienced a cyberattack reported negative effects on patient care,
including delays in tests or procedures, longer stays, and increased
mortality rates complications from medical procedures, and patient
transfers or diversions to other facilities.\144\ A recent letter from
NCVHS referenced anecdotal accounts of patient deaths that have been
attributed to ransomware attacks.\145\ For example, in 2019, a
ransomware attack may have contributed to a baby's death at an Alabama
hospital. A change in the baby's fetal heart rate went unnoticed
because the large digital display that normally would have displayed
the information was affected by the attack. The baby, born with her
umbilical cord wrapped around her neck, suffered severe brain damage
and died nine months later.\146\
---------------------------------------------------------------------------
\139\ ``CISA INSIGHTS: Provide Medical Care Is In Critical
Condition: Analysis and Stakeholder Decision Support to Minimize
Further Harm,'' Cybersecurity & Infrastructure Security Agency, U.S.
Department of Homeland Security, p. 12-15 (Sept. 2021), https://www.cisa.gov/sites/default/files/publications/CISA_Insight_Provide_Medical_Care_Sep2021.pdf.
\140\ Id.
\141\ See ``Assessing resilience of hospitals to cyberattack,''
supra note 130; Claire C. McGlave, et al., ``Hacked to Pieces? The
Effects of Ransomware Attacks on Hospitals and Patients,'' SSRN
(Oct. 4, 2023), https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4579292.
\142\ ``Hacked to Pieces? The Effects of Ransomware Attacks on
Hospitals and Patients,'' supra note 141, p. 14.
\143\ ``The 2024 Study on Cyber Insecurity In Healthcare: The
Cost and Impact on Patient Safety and Care,'' Ponemon Institute, p.
3 (2024) (The report, sponsored by Proofpoint, Inc., included 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. The
hospital lost access to its EHR, internet, and intranet, which also
``removed functionality of hospital phones, [EHR] integrated office and
surgical scheduling, access to digitized radiology studies, and network
account access through local and remote computers.'' \151\
---------------------------------------------------------------------------
\150\ Mitchell Tarka, et al., ``The crippling effects of a
cyberattack at an academic level 1 trauma center: An orthopedic
perspective,'' Injury, p. 1095-1101 (2023), https://pubmed.ncbi.nlm.nih.gov/36801172/ 36801172/.
\151\ Id.
---------------------------------------------------------------------------
These serious incidents and resulting effects demonstrate the
importance of planning and preparing for a potential
[[Page 909]]
cyberattack or other event that adversely affects a regulated entity's
information systems. While such planning and preparation may not
prevent all cyberattacks, it can reduce the number of successful
incidents and mitigate their effects. In fact, studies have suggested
that such preparation may allow for at least close to real-time
recovery.\152\
---------------------------------------------------------------------------
\152\ ``Assessing resilience of hospitals to cyberattack,''
supra note 130, p. 13.
---------------------------------------------------------------------------
The effects of a cyberattack are not limited to the regulated
entity that experiences it and the individuals whose ePHI is
compromised. Surveys conducted by various organizations representing
health care providers indicate that an overwhelming majority of health
care providers in the U.S. were affected by a ransomware attack on a
large health care clearinghouse.\153\ A study published in 2023
examined the effects on the of a cyberattack at a neighboring,
unaffiliated hospital on a large academic medical center.\154\ The
study found that the academic medical center experienced, among other
things, significant increases in the number of patients admitted,
ambulance arrivals, waiting room times, and patients leaving without
being seen. The study's authors concluded that their findings suggested
``that health care cyberattacks such as ransomware are associated with
greater disruptions to regional hospitals and should be treated as
disasters, necessitating coordinated planning and response efforts.''
\155\ Thus, implementing reasonable and appropriate security measures
better protects not only the regulated entity and its ePHI, but other
regulated entities with whom it interacts, and may reduce the effects
of cyberattacks and other security incidents that adversely affect the
confidentiality, integrity, or availability of ePHI.
---------------------------------------------------------------------------
\153\ See Paige Minemyer, ``AMA: 80% of docs have lost revenue
amid disruptions from Change Healthcare cyberattack,'' Fierce
Healthcare (Apr. 10, 2024), https://www.fiercehealthcare.com/practices/ama-80-docs-have-lost-revenue-amid-disruptions-change-healthcare-cyberattack; ``AHA survey: Change Healthcare cyberattack
having significant disruptions on patient care, hospitals'
finances'' (Mar. 15, 2024), https://www.aha.org/news/news/2024-03-15-aha-survey-change-healthcare-cyberattack-having-significant-disruptions-patient-care-hospitals-finances; see also Sean Lyngaas,
`` `We're hemorrhaging money': US health clinics try to stay open
after unprecedented cyberattack,'' CNN (Mar. 9, 2024), https://www.cnn.com/2024/03/09/tech/medical-supply-chain-cybersecurity/index.html.
\154\ Christian Dameff, et al., ``Ransomware Attack Associated
With Disruptions at Adjacent Emergency Departments in the U.S.,''
JAMA Network Open (May 8, 2023), https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2804585.
\155\ Id.
---------------------------------------------------------------------------
As discussed above, several industry organizations have published
and maintained compilations of voluntary standards, guidelines, best
practices, methodologies, procedures, and processes for protecting the
security of sensitive and confidential information, including PHI.
Additionally, certain Federal health programs now either require or
recommend the adoption of specific criteria that are intended to
protect the confidentiality, integrity, and availability of ePHI. For
example, the Health IT Certification Program maintained by the
Assistant Secretary for Technology Policy and Office of the National
Coordinator for Health Information Technology (ASTP/ONC) \156\ sets
minimum requirements for certified health IT, including criteria that
pertain to cybersecurity.\157\ These criteria are included in the
Health IT Certification Program's Health IT Privacy and Security
Framework,\158\ which identifies when technical capabilities to support
the privacy and security of electronic health information \159\ must be
included in certified health IT products. Additionally, health care
providers that participate in certain Federal health programs must use
health IT certified to these requirements.\160\ Regulated entities also
may want to consider adoption of certified health IT because it could
contribute to compliance with the Security Rule. We will continue to
work across the Department to ensure the adoption of consistent
requirements for Federal programs that support the secure electronic
exchange of health information to the extent that such consistency is
appropriate. Throughout this preamble, we provide examples of how a
regulated entity's participation in other Federal programs that require
the use of health IT certified through the ONC Health IT Certification
Program, or adoption of other Federal recommendations, such as the HHS
CPGs, might support their compliance with the proposals in this NPRM.
---------------------------------------------------------------------------
\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. 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. 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
[[Page 910]]
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. The compilations and regulations are designed to protect various
types of data and information systems broadly. In comparison, a
defining quality of the Security Rule's requirements is that they focus
specifically on the protection of ePHI and the information systems that
create, receive, maintain, or transmit ePHI. Thus, while the
foundational elements of various cybersecurity compilations and State
regulations and the Security Rule may be the same, the Security Rule
alone addresses the application of those elements to ePHI and all of
the components of information systems that create, receive, maintain,
or transmit ePHI. Thus, while the standards of the Security Rule
generally align with those of other cybersecurity standards,
frameworks, best practices, guidelines, processes, and procedures, the
specific implementation specifications of the Security Rule reflect the
particular sensitivities of the health care industry, particularly
small and rural health care providers, in a way that is necessary to
ultimately improve the efficiency and effectiveness of the health care
system and avoid imposing unreasonable compliance burdens on regulated
entities.
B. The Health Care Environment Has Changed Since the Security Rule Was
Last Revised and Will Continue To Evolve
The health care sector has undergone a dramatic transformation over
the last 24 years, and particularly in the past 10 years, spurred at
least in part by the Department's implementation of HIPAA, the HITECH
Act, and the Cures Act. The industry has shifted from one that
generally relied upon a system of paper-based recordkeeping and siloed
devices to one that depends on interconnected information systems to
maintain and exchange patient records, conduct research, run health
care provider facility management systems, and provide patient
care.\166\ This shift is largely the result of HIPAA's emphasis on the
development and use of standards and the EHR incentive funds made
available under the HITECH Act for health care providers.\167\ Data
from ASTP/ONC offer clear and convincing evidence of this shift. In
2008, before the enactment of the HITECH Act, less than 10 percent of
non-Federal acute hospitals had implemented what was referred to at the
time as a ``Basic EHR'' (i.e., an electronic health record).\168\ By
2015, six years after the enactment of the HITECH Act, almost 84
percent had adopted a Basic EHR while 96 percent had adopted a
certified EHR.\169\ The transformation was further enabled by the Cures
Act, which encouraged the development of a trusted exchange framework
for the nationwide exchange of health information and provided
penalties for health care providers, health information exchanges and
networks, and developers of certified health IT that engage in
information blocking.\170\ In 2014, 41 percent of such hospitals
routinely had electronic access to clinical information from outside
providers or sources when treating a patient.\171\ By 2023, 70 percent
of non-Federal acute care hospitals engaged in all domains of
interoperable exchange routinely or sometimes, a significant leap
forward.\172\ In 2017, only 38 percent of hospitals enabled patients to
access their health information using an application and in 2018, 57
percent enabled patient access to their clinical notes in their patient
portal; by 2021, 70 percent of hospitals enabled patients to access
their health information using an application and 82 percent enabled
patients to view their clinical notes in their patient portal.\173\ And
just a year later, the percentage of hospitals that supported patient
access through applications increased to 86 percent.\174\ Based on this
data, it is clear that HIPAA, coupled with the HITECH Act and the Cures
Act, has successfully encouraged the development of a nationwide
electronic health information system.
---------------------------------------------------------------------------
\166\ Derrick Tin, et al., ``Cyberthreats: A primer for health
care professionals,'' The American Journal of Emergency Medicine, p.
182-183 (Apr. 2023), https://doi.org/10.1016/j.ajem.2023.04.001.
\167\ See Public Law 104-191, 110 Stat. 2021 (Aug. 21, 1996)
(codified at 42 U.S.C. 1320d note); Sec. 4101 of ARRA, Public Law
111-5, 123 Stat. 467 (Feb. 17, 2009), amending sec. 1848 of the SSA
(codified at 42 U.S.C. 1395w-4).
\168\ JaWanna Henry, et al., ``ONC Data Brief: Adoption of
Electronic Health Record Systems among U.S. Non-Federal Acute Care
Hospitals: 2008-2015,'' The Office of the National Coordinator for
Health Information Technology, U.S. Department of Health and Human
Services, p. 1 (May 2016), https://www.healthit.gov/sites/default/files/briefs/2015_hospital_adoption_db_v17.pdf; A Basic EHR collects
information on patient demographics, problem lists, medication
lists, and discharge summaries. It also includes computerized
provider order entry for medications and enables clinicians to view
certain reports. Id. at Appendix.
\169\ ``ONC Data Brief: Adoption of Electronic Health Record
Systems among U.S. Non-Federal Acute Care Hospitals: 2008-2015,''
supra note 168, p. 1; When used here, ``certified EHR Technology''
means EHR technology that meets the technological capability,
functionality, and security requirements adopted by the Department
as certification criteria at 45 CFR part 170.; see also ``Certified
EHR Technology,'' The Office of the National Coordinator for Health
Information Technology, U.S. Department of Health and Human Services
(Sept. 6, 2013), https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs/certified-ehr-technology (``In
order to efficiently capture and share patient data, health care
providers need certified electronic health record (EHR) technology
(CEHRT) that stores data in a structured format. Structured data
allows health care providers to easily retrieve and transfer patient
information and use the EHR in ways that can aid patient care.'').
\170\ See sec. 4003(b) and 4004(b)(2) of Public Law 114-255, 130
Stat. 1165 (Dec. 13, 2016) (codified at 42 U.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. The coronavirus disease 2019 (COVID-19) pandemic led to
a dramatic increase in the use of telemedicine.\175\ According
[[Page 911]]
to ONC data, only 15 percent of office-based physicians used any form
of telemedicine in 2018-19. In 2021, telemedicine usage increased to 87
percent.\176\ The electronic content generated or transmitted during a
telemedicine visit constitutes ePHI, so the increase in telemedicine
further increases the amount of PHI that is also ePHI.
---------------------------------------------------------------------------
\175\ See ``Determination That A Public Health Emergency Exists
Nationwide as the Result of the 2019 Novel Coronavirus,''
Administration for Strategic Preparedness & Response, U.S.
Department of Health and Human Services (Jan. 31, 2020), https://aspr.hhs.gov/legal/PHE/Pages/2019-nCoV.aspx; ``Renewal of
Determination that a Public Health Emergency Exists As a Result of
the Continued Consequences of the Coronavirus Disease 2019 (COVID-
19) Pandemic,'' Administration for Strategic Preparedness &
Response, U.S. Department of Health and Human Services (Feb. 9,
2023), https://aspr.hhs.gov/legal/PHE/Pages/COVID19-9Feb2023.aspx;
``Notification of Enforcement Discretion for Telehealth Remote
Communications During the COVID-19 Nationwide Public Health
Emergency,'' Office for 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.
\179\ ``Guidance Document: Information for Healthcare
Organizations about FDA's `Guidance for Industry: Cybersecurity for
Networked Medical Devices Containing Off-The-Shelf (OTS) Software,'
'' U.S. Food & Drug Administration, U.S. Department of Health and
Human Services (Feb. 2005), https://www.fda.gov/regulatory-information/search-fda-guidance-documents/information-healthcare-organizations-about-fdas-guidance-industry-cybersecurity-networked-medical.
---------------------------------------------------------------------------
Cybercriminals may use--or target--technology assets, such as
software or medical devices used for treating individuals. For example,
in 2021, a cyberattack on cloud-based systems supplied by a particular
company compromised the ePHI of more than 200,000 individuals and
affected the software for linear accelerators used in radiotherapy,
leading to disruptions to cancer treatment.\180\ Thus, to protect
technology assets used for treatment, the information systems that
create, receive, maintain, and transmit ePHI also must be protected. As
another example, in 2013, the Mayo Clinic \181\ hired a group of
ethical hackers \182\ to identify vulnerabilities in 40 different
medical devices.\183\ The hackers were able to gain access to all of
the devices, meaning that the devices could all be vulnerable to a
cyberattack.\184\ Such attacks may create an opening for a subsequent
attack on the device itself or on the regulated entity's information
systems that create, receive, maintain, or transmit ePHI, compromising
those information systems and the ePHI itself.\185\ It also may lead,
intentionally or not, to a loss of device integrity, which could result
in the corruption of the device's functionality or the ePHI on the
device.\186\ A cyberattack on a medical device may also reduce the
ability of the authorized person to use the device (e.g., a denial of
service attack, which is a type of cyberattack that overloads the
device by flooding the network with traffic).\187\ Depending on the
device and its use, the result of cyberattacks on a medical device
could range from little or no effect to serious injury or death.\188\
---------------------------------------------------------------------------
\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.
\185\ See also ``It's Way Too Easy to Hack the Hospital,'' supra
note 183; Nicole M. Thomasian, et al., ``Cybersecurity in the
internet of Medical Things,'' Health Policy and Technology (Sept.
2021), https://doi.org/10.1016/j.hlpt.2021.100549.
\186\ ``Cybersecurity in the internet of Medical Things,'' supra
note 185.
\187\ Id.
\188\ Id.
---------------------------------------------------------------------------
According to researchers at Brown University, medical devices are a
prime target for cybercriminals. In fact, they believe, ``More than
just technically feasible, the widespread takedown of medical devices
is an imminent threat.'' \189\ A 2023 Government Accountability Office
report on medical device cybersecurity described the importance of
``robust cybersecurity controls to ensure medical device safety and
effectiveness'' because of ``the increasing integration of wireless,
internet- and network-connected capabilities, and the electronic
exchange of health information.'' \190\ The FDA has also acknowledged,
``As electronic medical devices become increasingly connected to each
other and to other technologies, the ability of connected systems to
safely, securely and effectively exchange and use the information
becomes critical. [. . .] Cybersecurity concerns rise along with the
increasing medical device interoperability.'' \191\ Accordingly, in
2023, the FDA issued updated guidance for industry and FDA staff on
requirements for cybersecurity in medical devices.\192\
---------------------------------------------------------------------------
\189\ Id.
\190\ Report to Congressional Committees, ``Medical Device
Cybersecurity: Agencies Need to Update Agreement to Ensure Effective
Coordination,'' U.S. Government Accountability Office, p. 1 (Dec.
2023), https://www.gao.gov/assets/d24106683.pdf.
\191\ ``Medical Device Interoperability,'' U.S. Food & Drug
Administration, U.S. Department of Health and Human Services,
https://www.fda.gov/medical-devices/digital-health-center-excellence/medical-device-interoperability.
\192\ Guidance for Industry and Food & Drug Administration
Staff, ``Cybersecurity in Medical Devices: Quality System
Considerations and Content of Premarket Submissions,'' U.S. Food &
Drug Administration, U.S. Department of Health and Human Services
(Sept. 27, 2023), https://www.fda.gov/media/119933/download.
---------------------------------------------------------------------------
And then there are digital health applications. When an application
is deployed by a covered entity, an application developer may be a
business associate and subject to the Security Rule. An application
developer may also meet the HIPAA Rules' definition of ``health care
provider'' \193\ and be a covered entity.\194\ But also, individuals
are increasingly interested in accessing their ePHI using applications
and transmitting information collected by health and wellness
applications to
[[Page 912]]
their health care providers.\195\ Such applications may empower
individuals to better manage their health and participate in their
health care and provide health care providers and researchers with a
more holistic view of the individual's health at a particular point in
time and over an extended period of time.\196\ This technology, while
valuable for understanding an individual's overall health, introduces
another potential vulnerability to the security of ePHI and the
information systems that create, receive, maintain, or transmit it.
---------------------------------------------------------------------------
\193\ 45 CFR 160.103 (definition of ``Health care provider'').
\194\ Where an application developer meets the HIPAA Rules'
definition of health care provider and engages in standard
electronic transactions, such as billing an insurance company for
its services, it is a covered entity for the purposes of the HIPAA
Rules, including the Security Rule. Where an application developer
is not regulated under the HIPAA Rules, other Federal laws may apply
to the application developer or the application, such as the FTC
Act. See, e.g., FTC Act (codified at 15 U.S.C. 41-58).
\195\ See, e.g., Kea Turner, et al., ``Sharing patient-generated
data with healthcare providers: findings from a 2019 national
survey,'' Journal of the American Medical Informatics Association,
p. 371-376 (Nov. 12, 2020), https://doi.org/10.1093/jamia/ocaa272;
Accenture Federal Services, ``Conceptualizing a Data Infrastructure
for the Capture, Use, and Sharing of Patient-Generated Health Data
in Care Delivery and Research through 2024,'' The Office of the
National Coordinator for Health Information Technology, U.S.
Department of Health and Human Services, p. 5 (Jan. 2018), https://www.healthit.gov/sites/default/files/onc_pghd_final_white_paper.pdf;
see also Jolaade Kalinowski, et al., ``Smart device ownership and
use of social media, wearable trackers, and health apps among Black
women with hypertension in the United States,'' JMIR Cardio (pre-
print), https://preprints.jmir.org/preprint/59243.
\196\ See ``Conceptualizing a Data Infrastructure for the
Capture, Use, and Sharing of Patient-Generated Health Data in Care
Delivery and Research through 2024,'' supra note 195, p. 1; Asos
Mahmood, et al., ``mHealth Apps Use and Their Associations With
Healthcare Decision-Making and Health Communication Among Informal
Caregivers: Evidence From the National Cancer Institute's Health
Information National Trends Survey,'' American Journal of Health
Promotion, p. 40-52 (Jan. 2024), https://journals-sagepub-com.hhsnih.idm.oclc.org/doi/10.1177/08901171231202861.
---------------------------------------------------------------------------
EHRs, networked medical devices, and applications are only the
beginning. Artificial intelligence (AI) in health care, particularly
for diagnosis and treatment, is in the nascent stages of development,
but many are eager to test its promise.\197\ After all, many experts
believe that AI promises opportunities to improve patient care,
outcomes, and population health, as well as to reduce costs.\198\ The
use of AI in health care is increasing and is expected to continue to
increase.\199\ A 2023 Healthcare Information and Management Systems
Society (HIMSS) survey of health care cybersecurity professionals
reported that approximately 50 percent of respondents' organizations
permitted the use of generative AI technology.\200\ And other new
technologies are expected shortly, as discussed below. For example,
according to reports, quantum computing may be available in the near
future, which may have ramifications for data privacy and
security.\201\ We also know that researchers are exploring methods for
storing ePHI in biological material (e.g., DNA).\202\
---------------------------------------------------------------------------
\197\ See 88 FR 75191 (Nov. 1, 2023); Ritu Agarwal, et al.,
``Augmenting physicians with artificial intelligence to transform
healthcare: Challenges and opportunities,'' Journal of Economics &
Management Strategy, p. 360-374 (Mar. 2024), https://onlinelibrary-wiley-com.hhsnih.idm.oclc.org/doi/10.1111/jems.12555; Becca Beets,
et al., ``Surveying Public Perceptions of Artificial Intelligence in
Health Care in the United States: Systematic Review,'' Journal of
Medical internet Research (2023), https://doi.org/10.2196/40337.
\198\ Michael E. Matheny, et al., ``Artificial Intelligence in
Health Care: A Report from the National Academy of Medicine,''
Journal of the American Medical Association, p. 509-10 (2020),
https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2757958.
\199\ ``2023 HIMSS Healthcare Cybersecurity Survey,'' Healthcare
Information and Management Systems Society, p. 19 (Mar. 1, 2024),
https://www.himss.org/sites/hde/files/media/file/2024/03/01/2023-himss-cybersecurity-survey-x.pdf.
\200\ Id. at 16; Generative AI is a type of software that ``uses
statistical models that generalize the patterns and structures of
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. required the Secretary of HHS, in consultation with the Secretary
of Defense and the Secretary of Veterans Affairs, to establish an HHS
AI Task Force to develop a strategic plan that includes policies and
frameworks on responsible deployment and use of AI and AI-enabled
technologies in the health and human services sector, including the
incorporation of safety, privacy, and security standards into the
software-development lifecycle for the protection of personally
identifiable information, such as measures to address AI-enhanced
cybersecurity threats in the health and human services sector.\204\ The
Department has taken a number of actions to address the use of AI in
health care, including establishing an AI Council, appointing a Chief
AI Officer,\205\ and taking steps to regulate the use of AI in health
care.\206\ Accordingly, regulated entities must be prepared to
identify, mitigate, and remediate such risks and vulnerabilities.
---------------------------------------------------------------------------
\203\ 88 FR 75191 (Nov. 1, 2023).
\204\ Id. at 75214.
\205\ See ``HHS Artificial Intelligence (AI) Strategy: AI
Council & AI Community of Practice,'' U.S. Department of Health and
Human Services (June 6, 2024), https://www.hhs.gov/programs/topic-sites/ai/strategy/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
[[Page 913]]
valuable than credit card data, enabling cybercriminals to extract as
much as [$1,000] per stolen medical record.'' \208\ Before this shift
to an interconnected electronic system, lost or misplaced paper records
or even a laptop could lead to a breach of unsecured PHI affecting
hundreds or thousands of individuals.\209\ While a breach of that size
remains significant, unauthorized access to a single workstation today
could lead to a breach that affects millions of individuals because of
the increase in interconnectivity.\210\
---------------------------------------------------------------------------
\207\ John Riggi, ``The importance of cybersecurity in
protecting patient safety,'' American Hospital Association Center
for Health Innovation, https://www.aha.org/center/cybersecurity-and-risk-advisory-services/importance-cybersecurity-protecting-patient-safety; In 2016, PHI was valued at 50 times the worth of financial
information on the black market. Diane Doebele Koch, ``Is the HIPAA
Security Rule Enough to Protect Electronic Personal Health
Information (PHI) in the Cyber Age?'' Journal of Health Care
Finance, p. 22 (Spring 2016) (citing Beth Kutscher, ``Healthcare
underspends on Cybersecurity as attacks accelerate,'' Modern
Healthcare (Mar. 3, 2016), https://www.modernhealthcare.com/article/20160303/NEWS/160309922/healthcare-underspends-on-cybersecurity-as-attacks-accelerate.); ``New Dangers in the New World: Cyber Attacks
in the Healthcare Industry,'' supra note 135, p. 3 (``[. . .] stolen
medical data sells for 10-20 times more than credit card data.'').
\208\ Gilbert Munoz-Cornejo, et al., ``Analyzing the urban-rural
divide: the role of location, time, and breach characteristics in
U.S. hospital security incidents, 2012-2021,'' Discover Health
Systems (June 17, 2024), https://link.springer.com/article/10.1007/
s44250-024-00105-
6#:~:text=Specifically%2C%20our%20study%20shows%20that,trend%20of%20b
reaches%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. 21, 2024, Optum (another subsidiary of
UnitedHealth Group) reported that it was ``experiencing enterprise-
wide connectivity issues.'' By that afternoon, the announcement
changed to a ``network interruption related to a cyber security
issue'' and explained that ``[o]nce [Change Healthcare] became aware
of the outside threat, in the interest of protecting our partners
and patients, we took immediate action to disconnect our systems to
prevent further impact.'' See ``Optum Solution Status,'' Optum,
Inc., UnitedHealth Group, https://solution-status.optum.com/incidents/hqpjz25fn3n7 (last accessed on July 16, 2024). On Mar. 13,
2024, the Department announced that it would be initiating an
investigation into the incident. See Letter from OCR Director
Melanie Fontes Rainer to Colleagues (Mar. 13, 2024), https://www.hhs.gov/sites/default/files/cyberattack-change-healthcare.pdf.
Andrew Witty, UnitedHealth Group Chief Executive Officer, in his
testimony to Congress, estimated that the breach of Change
Healthcare may involve the PHI of one-third of Americans. ``Hacking
America's Health Care: Assessing the Change Healthcare Cyber Attack
and What's Next,'' Subcommittee on Oversight and Investigations of
the Committee on Energy and Commerce, Hearing Before the Committee
on Finance (May 1, 2024), https://www.finance.senate.gov/hearings/hacking-americas-health-care-assessing-the-change-healthcare-cyber-attack-and-whats-next. Change Healthcare filed its breach report
with the Department on July 19, 2024. ``Breach Portal: Notice to the
Secretary of HHS Breach of Unsecured Protected Health Information,''
supra note 10. Change Healthcare's breach report currently
identifies 100 million individuals as the ``approximate number of
individuals affected.'' https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf. However, Change Healthcare is still determining
the number of individuals affected. The posting on the HHS Breach
Portal will be amended if Change Healthcare updates the total number
of individuals affected by this breach. ``Change Healthcare
Cybersecurity Incident Frequently Asked Questions,'' Office for
Civil Rights, U.S. Department of Health and Human Services, https://www.hhs.gov/hipaa/for-professionals/special-topics/change-healthcare-cybersecurity-incident-frequently-asked-questions/index.html.
---------------------------------------------------------------------------
In 2023, the Federal Bureau of Investigation's internet Crime
Complaint Center received almost 250 reports of ransomware affecting
the Healthcare and Public Health sector, the most of any of the 16
identified infrastructure sectors.\215\ The Healthcare and Public
Health sector has been the most targeted critical infrastructure sector
since at least as far back as 2015.\216\ Between 2015 and 2019,
cyberattacks on health care organizations increased by 125
percent.\217\ And between 2022 and 2023, ransomware attacks against the
U.S. health care sector increased 128 percent.\218\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
\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
[[Page 914]]
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.
\224\ Press release, ``Snooping in Medical Records by Hospital
Security Guards Leads to $240,000 HIPAA Settlement,'' Office for
Civil Rights, U.S. Department of Health and Human Services (June 15,
2023), https://www.hhs.gov/about/news/2023/06/15/snooping-medical-records-by-hospital-security-guards-leads-240-000-hipaa-settlement.html.
---------------------------------------------------------------------------
Emergencies or other occurrences can affect the security of ePHI
without an intentional act. For example, in 2024, CrowdStrike released
a defective update for its software on computers running Microsoft
Windows.\225\ This update affected the ability of regulated entities to
access the ePHI of millions of individuals for varying periods of time.
During this time, ePHI was unavailable, meaning that one of the key
prongs of the security triad of confidentiality, integrity, and
availability was affected.\226\ Because of the increased digitization
of PHI, it is, for example, essential that covered health care
providers engage in thoughtful contingency planning that considers how
they will proceed in the event that they are unable to access ePHI in
their EHRs. Additionally, threat actors will often seek to take
advantage of such incidents. As reported by a large subcontractor of a
business associate, less than a week after the outage, the company
``observed threat actors leveraging the event to distribute''
ransomware.\227\ The environment in which health care is delivered, the
way in which it is delivered, and the manner in which related
information is collected all mean that regulated entities must consider
a different approach to operational continuity and resiliency in the
face of such challenges. Additionally, they must be wary of the
potential for bad actors to attempt to take advantage of such events.
---------------------------------------------------------------------------
\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. 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. 2 (explaining that NCVHS conducted an inquiry into whether
compliance with the Security Rule had improved since the Department
released the results of its 2016-2017 audit of selected provisions
of the Security Rule and found that ``not much had changed'');
``Muddling through cybersecurity: Insights from the U.S. healthcare
industry,'' supra note 116, p. 540 (``There is enough evidence to
suggest that U.S. healthcare organizations lack a deliberate,
organized, and comprehensive cyber-resilience strategy.'').
\229\ See Susan Kiser, et al., ``Ransomware: Healthcare Industry
at Risk,'' Journal of Business and Accounting, p. 65-66 (Fall 2021);
Meghan Hufstader Gabriel, ``Data Breach Locations, Types, and
Associated Characteristics Among US Hospitals,'' American Journal of
Managed Care, p. 78 (Feb. 2018); ``Is the HIPAA Security Rule Enough
to Protect Electronic Personal Health Information (PHI) in the Cyber
Age?'' supra note 207, p. 20-23.
\230\ Chris Hayhurst, ``On Guard: Staying Vigilant Against
Medical Device Vulnerabilities,'' Biomedical Instrumentation &
Technology, Volume 54, Issue 3, p. 169 (May/June 2020); ``Report 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). In the preamble to
the 2003 Security Rule, the Department explained that it had
determined that an inventory requirement was unnecessary because it
is redundant of other requirements. We assumed that covered entities
(and later all regulated entities) would have performed this
activity by virtue of having implemented the security measures
required under the security management process standard.
\235\ ``Muddling through cybersecurity: Insights from the U.S.
healthcare industry,'' supra note 116, p. 542-543.
\236\ Eric C. Reese, ``Healthcare's cybersecurity stakes reach
alarming levels,'' Health Facilities Management Magazine, Volume 76,
Issue 8, p. 22 (Nov. 2022).
---------------------------------------------------------------------------
The security of ePHI also is at risk because, despite our
explanation of the Security Rule's structure in 2003,\237\ regulated
entities are not fully complying with the standards and implementation
specifications. From 2016 to 2017, the Department conducted audits of
166 covered entities and 41 business associates regarding compliance
with selected provisions of the HIPAA Rules, including the required
implementation specifications for risk analysis \238\ and risk
management.\239\ The Department found that most regulated entities
failed to implement the Security Rule requirements for risk analysis
and risk management, requirements that are fundamental to protecting
the confidentiality, integrity, and availability of ePHI.\240\ While
most of the audited business associates reported not having experienced
any breaches of unsecured PHI, we found that those that
[[Page 915]]
had experienced a breach generally engaged in minimal or negligible
efforts to address the risk analysis and risk management
requirements.\241\ According to the report, at that time only 14
percent of covered entities and 17 percent of business associates were
``substantially fulfilling their regulatory responsibilities to
safeguard ePHI they [held] through risk analysis activities,'' \242\
while 94 percent of covered entities and 88 percent of business
associates ``failed to implement appropriate risk management activities
sufficient to reduce risks and vulnerabilities to a reasonable and
appropriate level.'' \243\ The report specifically noted that the audit
results were consistent with the findings of OCR's compliance reviews
and complaint investigations.\244\
---------------------------------------------------------------------------
\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.\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.
---------------------------------------------------------------------------
As another example, an OCR investigation of a large health care
system found indications of multiple potential violations of the
Security Rule, including failures by the regulated entity to conduct a
risk analysis, monitor and safeguard its electronic information
systems, and implement policies and procedures to record and examine
activity in its electronic information systems containing ePHI.\248\
The regulated entity was not only unable to prevent the cyberattack,
but it was unaware the attack had occurred until two years later. This
is despite the long-standing requirements of the Security Rule and the
obligations imposed on regulated entities for risk analysis and risk
management.
---------------------------------------------------------------------------
\248\ See Resolution Agreement, ``Montefiore Medical Center,''
Office for Civil Rights, U.S. Department of Health and Human
Services (Nov. 17, 2023), https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/montiefore/index.html; ``HHS' Office for Civil Rights Settles Malicious Insider
Cybersecurity Investigation for $4.75 Million,'' supra note 223.
---------------------------------------------------------------------------
Despite the long-standing nature of the Security Rule and the
proliferation of guidance documents from NIST, the Department, CISA,
FTC, and others, regulated entities continue to fail to implement
reasonable and appropriate security measures as required by the
Security Rule.\249\ For example, the Security Rule and NIST guidance
have addressed encryption for data in transit and at rest for many
years.\250\ And yet, in the 2021 survey of health care cybersecurity
professionals, only half of the respondents reported having implemented
encryption for data in transit across the enterprise.\251\ Similarly,
according to its CEO, a large covered entity failed to deploy multi-
factor authentication (MFA) throughout its enterprise and experienced a
significant breach.\252\ If this is accurate, it would run counter to
long-standing provisions in both the Security Rule and NIST guidance;
the Security Rule has required the implementation of appropriate access
controls since 2003 and NIST recommends similar controls.\253\
---------------------------------------------------------------------------
\249\ ``Muddling through cybersecurity: Insights from the U.S.
healthcare industry,'' supra note 116, p. 541; ``Start with
Security: A Guide for Business,'' supra note 17.
\250\ See 45 CFR 164.312(a)(1) and (e)(1); PR.DS-1 and 2,
``Framework for Improving Critical Infrastructure Cybersecurity,''
Cybersecurity Framework (CSF) Version 1.1, National Institute of
Standards and Technology, U.S. Department of Commerce (Apr. 16,
2018), https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf; PR.DS-01 and 02, ``The NIST Cybersecurity
Framework (CSF) 2.0,'' supra note 15.
\251\ ``2021 HIMSS Healthcare Cybersecurity Survey,'' supra note
231, p. 23.
\252\ See ``Hacking America's Health Care: Assessing the Change
Healthcare Cyber Attack and What's Next,'' supra note 214 (According
to CEO Andrew Witty, intruders used compromised credentials to
remotely access an application used to enable remote access to
desktops, which did not have MFA.). The Department's investigation
into the Change Healthcare breach is ongoing, and no conclusion has
been reached with respect to its cause or whether Change Healthcare
was in violation of the Security Rule.
\253\ 45 CFR 164.308(a)(4)(ii)(B) and 164.312(a)(1); ``The NIST
Cybersecurity Framework (CSF) 2.0,'' supra note 15; ``Framework for
Improving Critical Infrastructure Cybersecurity,'' supra note 250.
---------------------------------------------------------------------------
As another example, based on OCR's investigation experience, some
regulated entities are not developing and implementing compliant
response plans for security incidents, including those that are
breaches of unsecured ePHI under the Breach Notification Rule. Section
164.308(a)(6)(i) establishes the standard that requires regulated
entities to implement policies and procedures to address security
incidents, while 45 CFR 164.308(a)(6)(ii) includes the implementation
specifications for that standard. This requirement, included in the
2003 Final Rule, aligns with the NIST Cybersecurity Framework version
2.0 requirement for incident management.\254\ Similarly, NIST
Cybersecurity Framework version 1.1 recommended the execution and
maintenance of response processes and procedures to ensure response to
detected cybersecurity incidents.\255\ And yet, when OCR investigates
the circumstances surrounding breach reports, OCR continues to find
evidence that regulated entities have not implemented policies and
procedures to detect and respond to security incidents, leading to
significant time lapses between a ``successful'' security incident
\256\ and discovery of, and response to, the security incident.\257\
Thus, based on the OCR's experience investigating and enforcing the
Security Rule, the Department believes that many regulated entities
would benefit from additional instruction in regulatory text regarding
their compliance obligations to determine how to select security
[[Page 916]]
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.\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. Given that written policies and procedures alone are
insufficient to protect ePHI, and the misinterpretation of what it
means to implement a mechanism also could lead to inadequate protection
of ePHI, the Department believes that the Security Rule must be
revised, consistent with its statutory mandate, as discussed in greater
detail above.
D. It Is Reasonable and Appropriate To Strengthen the Security Rule To
Address the Changes in the Health Care Environment and Clarify the
Compliance Obligations of Regulated Entities
1. Congress and the Department Anticipated That Security Standards
Safeguards Would Evolve To Address Changes in the Health Care
Environment
By requiring that regulated entities maintain reasonable and
appropriate safeguards to protect against reasonably anticipated
threats or hazards or unauthorized uses or disclosures of ePHI,
Congress clearly anticipated that the administrative, physical, and
technical safeguards implemented to protect the security of ePHI would
need to change in response to changes in the environment in which
health care is provided.\261\ As the health care environment and the
operations of regulated entities evolve, so must the protections for
ePHI and the information systems used to create, receive, maintain, or
transmit it. For example, regulated entities must be expected to adopt
safeguards that address new risks to the security of ePHI, such as
those posed by maintaining ePHI in the cloud; the connection of medical
devices and other technology to networks; and the connection of
information systems used to create, receive, maintain, or transmit ePHI
to the same networks as those do not perform such activities. After
all, it is reasonable to anticipate that there will be new threats or
hazards to ePHI or efforts by unauthorized persons to use or disclose
such ePHI in an increasingly connected environment.
---------------------------------------------------------------------------
\261\ Sec. 1173(d)(2)(B) of Pub. L. 104-191, 110 Stat. 2026
(Aug. 21, 1996) (codified at 42 U.S.C. 1320d-2).
---------------------------------------------------------------------------
By design, the Security Rule sets a national floor for the security
measures that regulated entities are required to implement to protect
the confidentiality, integrity, and availability of ePHI. In 2003, the
Department opted to frame the standards in terms that were as generic
as possible and in a manner that enabled the standards to be met
through various approaches or technologies to ensure that regulated
entities had the flexibility to determine how best to protect the
confidentiality, integrity, and availability of ePHI based on their
specific circumstances.\262\ When we extended the Security Rule in 2013
to directly apply to business associates in accordance with the HITECH
Act,\263\ the Department acknowledged that some business associates
might not have engaged in the formal administrative safeguards required
by the Security Rule, and we made it clear that business associates
would be expected to do so going forward.\264\ Despite the changes in
the health care environment between 2003 and 2013, the Department made
minimal changes to the Security Rule at that time because we believed
that the compliance obligations of regulated entities were clear and
well-understood. In fact, when a commenter recommended that the
Department remove the ``addressable'' designation from the Security
Rule because it leads to ambiguity in the rule's application, we
declined to do so at that time because we were concerned that it would
reduce the rule's scalability and flexibility.\265\ However, as we
noted in 2003, the rule's flexibility of approach is primarily provided
for in paragraph (b)(2) of 45 CFR 164.306 and in the standards
themselves.\266\ The addressability feature merely provided an added
level of flexibility \267\ in a way that the Department now believes is
inadequate to ensure that regulated entities implement reasonable and
appropriate security safeguards.
---------------------------------------------------------------------------
\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. While we recognize the
burdens posed by such implementation on regulated entities, there is
also a clearly documented increase in the number of breaches of
unsecured PHI and instances of cybercriminals accessing ePHI without
authorization at regulated entities. The changes to the health care
environment, including the increase in breaches and cyberattacks, and
operations of regulated entities have made it increasingly likely that
unauthorized persons will seek to obtain ePHI and disrupt the U.S.
health care system. Additionally, the clearly documented failure of
regulated entities to fully implement the policies and procedures
required by the Security Rule and apply the required security measures
throughout their operations has caused the Department to question
whether the existing Security Rule should be revised to clarify and
strengthen the obligations of regulated entities and revisit our
[[Page 917]]
decision from 2013.\268\ In many cases involving a breach of ePHI that
OCR has investigated, a breach may not have occurred, or would have
been less widespread and disruptive, had the regulated entities fully
implemented the provisions of the Security Rule.\269\
---------------------------------------------------------------------------
\268\ See ``2016-2017 HIPAA Audits Industry Report,'' supra note
121, p. 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.\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.
---------------------------------------------------------------------------
Include specific minimum cybersecurity hygiene
requirements that are reflective of modern industry best practices,
including designation of a qualified information security official,
elimination of default passwords, adoption of MFA, institution of
offline backups, installation of critical patches within a reasonable
time, and transparency of impact and vulnerability disclosures.\276\
---------------------------------------------------------------------------
\276\ See Letter from NCVHS Chair Jacki Monson (2022), supra
note 123, p. 5-10; see also Letter from NCVHS Chair Jacki Monson
(2023), supra note 123, Appendix p. 2.
---------------------------------------------------------------------------
Require that regulated entities implement a security
program and that they implement standard minimum security
controls.\277\
---------------------------------------------------------------------------
\277\ Letter from NCVHS Chair Jacki Monson (2023), supra note
123, Appendix p. 1-4.
---------------------------------------------------------------------------
Require that regulated entities adopt a risk-based
approach in their security program.\278\
---------------------------------------------------------------------------
\278\ Id. at Appendix p. 4-5.
---------------------------------------------------------------------------
Require that regulated entities perform a risk analysis in
a manner that conforms with guidance from NIST and CISA.\279\
---------------------------------------------------------------------------
\279\ Id. at Appendix p. 4-6.
---------------------------------------------------------------------------
Define compensating controls more specifically and provide
a wider range of examples that apply to a greater variety of types of
entities.\280\
---------------------------------------------------------------------------
\280\ Id. at Appendix p. 6-7.
---------------------------------------------------------------------------
Reinforce the need for regulated entities to account for
AI systems and data within their risk analysis for all and any new
technology.\281\
---------------------------------------------------------------------------
\281\ Id. at Appendix p. 7-8.
---------------------------------------------------------------------------
Establish a consistent floor for cyber incident reporting
and harmonize such requirements with incident reporting provisions
applicable to health care critical infrastructure actors and health
care Federal contractors.\282\
---------------------------------------------------------------------------
\282\ Id. at 9-10.
---------------------------------------------------------------------------
The Department, in drafting this NPRM, relied on the
recommendations of NCVHS, OCR's enforcement experience, news reports,
and our assessment of the environment. Consistent with NCVHS'
recommendation to revisit the Security Rule's classification of some
implementation specifications as ``addressable,'' the Department also
believes that it is appropriate to revisit our decision regarding the
amount of flexibility regulated entities have in determining reasonable
and appropriate safeguards, as described above. Based on OCR's
experience in investigations and audits, we believe that regulated
entities would benefit from greater specificity in the Security Rule.
The Department has provided extensive guidance on questions to consider
when adopting and implementing security measures and ways to comply
with the Security Rule,\283\ as directed by the HITECH Act. And yet,
despite this proliferation of guidance, regulated entities continue not
to comply. For example, despite the explanation in 45 CFR 164.306(d)
about addressable implementation specifications and the notable changes
in the environment in which health care is provided, we are concerned
that some regulated entities proceed as if compliance with an
addressable implementation specification is optional--and that where
there is an addressable implementation specification, that compliance
with the relevant standard is also optional. That interpretation is
incorrect and weakens the cybersecurity posture of regulated entities.
We believe that compliance with the implementation specifications
currently designated as addressable is not--and should not be--
optional, particularly in light of the shift to an interconnected and
cloud-based environment and a significant increase in the number of
breaches of unsecured PHI from both internal and external actors,
regardless of the regulated entity's specific circumstances. Thus, we
believe that it is necessary to strengthen the Security Rule to reflect
the changes in the health care environment and the evolution of
[[Page 918]]
technology and to underscore that compliance with all of our proposals,
if finalized, is required.
---------------------------------------------------------------------------
\283\ The Department has issued, among other things, a video
presentation on trends in real world cyberattacks, a cybersecurity
checklist and infographic, guidance on ransomware, a crosswalk with
the NIST CSF, and an ongoing series of newsletters on various topics
pertaining to cybersecurity. See ``Cyber Security Guidance
Material,'' Office for Civil Rights, U.S. Department of Health and
Human Services, https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/index.html.
---------------------------------------------------------------------------
3. A Strengthened Security Rule Would Continue To Be Flexible and
Scalable While Providing Regulated Entities With Greater Clarity
The Security Rule's fundamental flexibility and scalability
generally would remain should the proposals in this NPRM be adopted.
However, we are proposing to reduce that flexibility to better
strengthen protections and address the changed nature of the
environment in which health care is provided. The Department is also
proposing in this NPRM to strengthen the Security Rule by providing
greater clarity regarding the nature of its flexibility and scalability
and the Department's expectations, as requested by regulated entities
and other stakeholders. In fact, in response to a request for
information published in 2022,\284\ several commenters urged the
Department to propose regulations that establish a single set of clear
standards for regulated entities, raise the floor for security
requirements and expectations, and encourage regulated entities to
safeguard ePHI while maintaining flexibility and scalability.
Commenters also encouraged the Department to rely on commonly
available, non-proprietary frameworks that allow regulated entities to
adopt critical security measures. We believe that our proposals are
consistent with those recommendations.
---------------------------------------------------------------------------
\284\ See 87 FR 19833 (Apr. 6, 2022).
---------------------------------------------------------------------------
Under the proposal, regulated entities would retain the ability to
determine the security measures that are reasonable and appropriate to
fulfill the required standards and implementation specifications,
taking into consideration the factors listed at proposed 45 CFR
164.306(b)(2). In fact, the NPRM, if adopted as proposed, would add to
the rule's flexibility and scalability by adding a new factor for
regulated entities to consider when determining the reasonable and
appropriate security measures.\285\
---------------------------------------------------------------------------
\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.\289\ As we
noted, ``Cost is not meant to free covered entities from this
responsibility.'' \290\ In the 2013 Omnibus Rule, we further explained
that ``[regulated entities] have the flexibility to choose security
measures appropriate for their size, resources, and the nature of the
security risks they face, enabling them to reasonably implement any
given Security Rule standard. [. . .] Thus, the costs of implementing
for [. . .] business associates will be proportional to their size and
resources.'' \291\ We continue to believe that this is the case.
Additionally, as discussed above, there is a significant cost
associated with breaches and unauthorized access--financial,
reputational (for both the individual and the regulated entity), and
more. Thus, we believe that the standards and implementation
specifications that we propose in this NPRM are the minimum that
regulated entities should be doing to protect the security of ePHI and
lower the costs associated with breaches and other incidents.
---------------------------------------------------------------------------
\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. Such rural areas generally have fewer health
care providers overall.), https://www.gao.gov/blog/why-health-care-harder-access-rural-america.
\294\ See ``A National Staffing Emergency in Rural Health
Care,'' American Hospital Association (Dec. 19, 2023), https://www.aha.org/advancing-health-podcast/2023-12-20-national-staffing-emergency-rural-health-care.
\295\ See Debi Primeau, ``How Small Organizations Handle HIPAA
Compliance,'' Journal of the American Health Information Management
Association, Volume 88, Issue 4, p. 18-21, 19 (Apr. 2017); Kat
Jercich, ``Rural hospitals are more vulnerable to cyberattacks--
here's how they can protect themselves,'' Healthcare IT News (Sept.
8, 2021); see also Tami Lichtenberg, ``Recovering from a
Cybersecurity Attack and Protecting the Future in Small, Rural
Health Organizations'' (Oct. 4, 2023), https://www.ruralhealthinfo.org/rural-monitor/cybersecurity-attacks.
\296\ See ``How Small Organizations Handle HIPAA Compliance,''
supra note 295, p. 19; ``Rural hospitals are more vulnerable to
cyberattacks--here's how they can protect themselves,'' supra note
295.
---------------------------------------------------------------------------
We continue to believe that it is just as important for small and
rural health care providers to implement strong security measures as it
is for larger health care providers and other categories of regulated
entities. According to experts, ``Cybercriminals go after small
businesses, especially those in the healthcare industry,
[[Page 919]]
because they are easy targets.'' \297\ In 2017, 93 percent of small
rural and critical access hospitals and 86 percent of physician offices
relied on health IT to inform their clinical practice.\298\ And yet,
small health care providers are less likely than a larger organization
to even have a designated security or compliance officer.\299\ Smaller
practices and rural and community facilities also may be more likely to
rely on older technologies that are no longer supported by security
patches and updates, including medical devices such as insulin pumps
and pacemakers in which inaccuracies or errors could affect patient
safety.\300\ Thus, small health care providers ``are at the greatest
risk of a breach. [. . .] Smaller, rural practice settings are
especially high-risk target areas for a breach.'' \301\ According to an
expert who speaks to and works with health care providers on IT
services and cybersecurity, small health care providers are ``more
susceptible because they do not have a lot of the tools and security
measures necessary to protect themselves.'' \302\ For example, a
critical access hospital in Colorado recovered from a cyberattack in
2019, but it required ``an incredible amount of staff time, many months
of recovery efforts, and an enormous financial outlay to restore
systems and prevent another attack.'' \303\ In fact, the hospital
estimates that ``it took a full year of a staff person's time to
complete the recovery and protect the organization for the future.''
\304\ These costs do not include the multiple ransoms paid to the
attackers after the first set of keys did not unlock all of the
data.\305\
---------------------------------------------------------------------------
\297\ ``Too Small to Be Attacked by Cybercriminals? Not So
Fast,'' Same-Day Surgery, Volume 43, Issue 7 (July 2019), https://www.reliasmedia.com/articles/144561-too-small-to-be-attacked-by-cybercriminals-not-so-fast.
\298\ ``Percent of Hospitals, By Type, that Possess Certified
Health IT,'' Health IT Quick-Stat #52 (Sept. 2018), https://www.healthit.gov/data/quickstats/percent-hospitals-type-possess-certified-health-it; ``Office-based Physician Electronic Health
Record Adoption,'' Health IT Quick-Stat #50, https://www.healthit.gov/data/quickstats/office-based-physician-electronic-health-record-adoption.
\299\ ``How Small Organizations Handle HIPAA Compliance,'' supra
note 295, p. 19.
\300\ See id.
\301\ Id.; see also ``Recovering from a Cybersecurity Attack and
Protecting the Future in Small, Rural Health Organizations,'' supra
note 295.
\302\ ``Too Small to Be Attacked by Cybercriminals? Not So
Fast,'' supra note 297.
\303\ ``Recovering from a Cybersecurity Attack and Protecting
the Future in Small, Rural Health Organizations,'' supra note 295.
\304\ Id.
\305\ Id.
---------------------------------------------------------------------------
Patients and communities have a critical need for health care
providers, including rural hospitals and other rural health care
providers, to be resilient and remain operational, which depends in
part on the cybersecurity of their electronic information systems. For
rural health care providers, especially hospitals, a breach can
significantly affect an entire community.\306\ Rural health care
providers often are separated by significant distances, which can have
real consequences for someone experiencing a medical emergency.\307\ A
recent study comparing hospital characteristics and operations of rural
and urban hospitals that experienced ransomware attacks between 2016
and 2021 found that rural hospitals experienced large declines in
inpatient admissions and Medicare revenue, similar to those experienced
by urban hospitals.\308\ The study also found that the decline in
volume and revenue of hospital outpatient and emergency room visits was
more pronounced among rural facilities.\309\ In fact, in June 2023, a
hospital in rural Illinois announced that it would close, in part
because a 2021 cyberattack prevented it from submitting claims to
health plans for months.\310\ According to a local elected official,
the hospital's closure would require some residents to travel
approximately 30 minutes for the nearest emergency room and obstetrics
services.\311\ Thus, implementing security measures to maintain
facility operations is critical to minimize or avoid disruptions to
patient care and patient safety activities in such facilities.
Consistent with these examples, the Department believes that small and
rural health care providers are also viewed as potential targets by
cybercriminals, and such providers need to implement strong
cybersecurity measures to secure the ePHI in their possession. In fact,
in June 2024, the Administration announced a collaboration with the
private sector to provide additional cybersecurity resources for rural
health care providers in recognition of the importance of protecting
the security of ePHI created, received, maintained, or transmitted by
such entities.\312\ We believe this collaboration will provide small
and rural health care providers with additional support, particularly
when coupled with other resources described in greater detail
below.\313\ Thus, we believe that small and rural health care providers
have both the need to comply with the proposals in this NPRM and the
capability of doing so. Additionally, we believe that the NPRM would
continue to provide all regulated entities, including small and rural
health care providers, the ability to take into account their
circumstances when determining which security measures are reasonable
and appropriate.\314\
---------------------------------------------------------------------------
\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.
\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. 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
[[Page 920]]
prevent all breaches or interruptions in the confidentiality,
integrity, or availability of ePHI, we believe that it will prevent
many and enable regulated entities to identify, mitigate, and remediate
the damage more quickly if there is a breach or other security
incident, thereby reducing harm to individuals and the overall costs of
such occurrences to regulated entities and to the U.S. health care
system. As such, the proposed modifications would support a primary
goal of HIPAA's Administrative Simplification provisions: improving the
efficiency and effectiveness of the U.S. health care system by
encouraging the development of health information systems through the
establishment of uniform standards and requirements for electronic
transmission of ePHI, including those for security.\316\
---------------------------------------------------------------------------
\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. The Secretary Must Develop Standards for the Security of ePHI
Because None Have Been Developed by an ANSI-Accredited Standard Setting
Organization
HIPAA requires the Secretary to adopt standards that have been
developed, adopted, or modified by a standard setting organization
accredited by ANSI, except in certain circumstances.\317\ For example,
HIPAA permits the Secretary to develop standards where no relevant
standards have been developed, adopted, or modified by an ANSI-
accredited standard setting organization. In developing, adopting, or
modifying a standard, the Secretary is required to consult with
standard setting organizations, NCVHS, and with the appropriate Federal
and State agencies.\318\
---------------------------------------------------------------------------
\317\ 42 U.S.C. 1320d-1(c)(1) and (2).
\318\ 42 U.S.C. 1320d-1(c)(2)(B).
---------------------------------------------------------------------------
The statutory definition of the term ``standard'' applies only to
standards for electronic transactions and data elements for such
transactions that are appropriate for: (1) the financial and
administrative transactions described in the statute; and (2) other
financial and administrative transactions consistent with the goals of
improving the operation of the health care system and reducing
administrative costs, as determined appropriate by the Secretary.\319\
Under HIPAA, security is not considered a financial or administrative
transaction, or a data element of such transaction.\320\ In the
``Health Insurance Reform: Standards for Electronic Transactions''
final rule in 2000, we explicitly adopted a broader definition of
``standard'' because we recognized that the statutory definition only
applied to standards for financial and administrative transactions,
despite the statute's requirement that the Secretary adopt standards
addressing other matters, including privacy and security.\321\ At that
time, we explained that we adopted a broader definition of standard to
accommodate the varying functions of the specific standards proposed in
other HIPAA regulations.\322\ For the same reason, we believe that it
is appropriate to continue to rely on the regulatory definition of
standard.\323\
---------------------------------------------------------------------------
\319\ See 42 U.S.C. 1320d(7) (definition of ``Standard'').
\320\ See 42 U.S.C. 1320d-2(a)(1).
\321\ 65 FR 50312, 50320 (Aug. 17, 2000); see also 42 U.S.C.
1320d-2(b), (c), and (d); sec. 264(c) of HIPAA.
\322\ 65 FR 50312, 50320 (Aug. 17, 2000).
\323\ 45 CFR 160.103 (definition of ``Standard'').
---------------------------------------------------------------------------
As discussed above, in both 1998 and 2003, the Department
determined that no comprehensive, scalable, and technology-neutral set
of standards exists, and accordingly, we proposed and adopted a new
standard.\324\ In 2013, we made only minor modifications to the
standards when we complied with explicit directions from Congress to
apply the requirements of the Security Rule to business associates, so
we did not need to consider whether an ANSI-accredited standard setting
organization had adopted a comprehensive set of standards on the
security for ePHI that was flexible, scalable, and technology-
neutral.\325\
---------------------------------------------------------------------------
\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. 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.
---------------------------------------------------------------------------
Additionally, in 2021, Congress amended the HITECH Act to require
the Secretary to consider whether a regulated entity has adequately
demonstrated that it had in place recognized security practices for a
certain period of time.\329\ Congress defined ``recognized security
practices'' to include certain NIST publications; the approaches
promulgated under
[[Page 921]]
section 405(d) of the Cybersecurity Act of 2015; ``and other programs
and processes that address cybersecurity and that are developed,
recognized, or promulgated through regulations under other statutory
authorities.'' \330\ However, the HITECH Act amendment did not require
the Secretary to accept a regulated entity's implementation of
recognized security practices as an alternative to compliance with the
Security Rule, nor did it provide that such implementation was
sufficient to meet the security objectives of HIPAA or the HITECH Act.
Accordingly, it is appropriate for the Department to develop and adopt
its own standards to meet the statutory objective of ensuring the
security of ePHI. The standards and implementation specifications
proposed herein take into consideration not only those promulgated by
NIST, but also guidelines, best practices, methodologies, processes,
and procedures published by CISA, the HHS 405(d) program, CMS, State
governments, and others. The proposals also enable regulated entities
to adopt security measures that ensure the confidentiality, integrity,
and availability of ePHI; protect against any reasonably anticipated
threats or hazards to the security or integrity of ePHI and
unauthorized uses or disclosures of such ePHI; ensure compliance with
the Security Rule by the workforce members of regulated entities, while
also taking into account the technical capabilities of record systems
used to maintain ePHI; the costs of such measures; the need for
training users who have access to ePHI; the value of audit trails in
computerized record systems; and the needs and capabilities of small
and rural health care providers.
---------------------------------------------------------------------------
\329\ See section 13412(a) of the HITECH Act, as amended by
section 1 of Public Law 116-321, 134 Stat. 5072 (Jan. 5, 2021)
(codified at 42 U.S.C. 17941(a)(1)).
\330\ Id.
---------------------------------------------------------------------------
The Department has consulted with and relied on the recommendations
of NCVHS in the formulation of this proposed rule \331\ and intends to
continue to engage in these consultations before finalizing the
rule.\332\ We also expect to consult with the National Uniform Billing
Committee, the National Uniform Claim Committee, the Workgroup for
Electronic Data Interchange, and the American Dental Association before
finalizing this rule, as required by section 1172(c)(3)(A)(ii) of
HIPAA.\333\
---------------------------------------------------------------------------
\331\ See Letter from NCVHS Chair Jacki Monson (2022), supra
note 123; Letter from NCVHS Chair Jacki Monson (2023), supra note
123.
\332\ 42 U.S.C. 1320d-1(f).
\333\ 42 U.S.C. 1320d-1(c)(3)(A)(ii).
---------------------------------------------------------------------------
IV. Section-by-Section Description of the Proposed Amendments to the
Security Rule
This section contains a description of the proposed amendments to
the Security Rule and the Department's rationale for its proposals. As
part of this rationale, we often include a discussion of best practices
contained in previously published guidance documents issued by the
Department, NIST, and other Federal agencies. We request comment on
previously published guidance documents that are not discussed herein
that were issued by the Department or other Federal agencies and
contain best practices but may be relevant or applicable to regulated
entities, including the names of and citations for such guidance
documents. We do not propose to adopt referenced best practices as the
standard or implementation specifications unless otherwise specified in
the proposed regulatory text. Rather, we include such discussion to
provide regulated entities with context for the aforementioned
proposals. We recognize that regulated entities are of varying types
and sizes and may be concerned that requiring the adoption of such best
practices might not be appropriate for all. However, we request comment
on whether we should require implementation of certain aspects of a
particular guidance document. If so, please explain which aspect(s) we
should require, the rationale, and information about the burden of
implementing such aspect(s).
A. Section 160.103--Definitions
1. Current Provision
Electronic media are used by many health care organizations to
process, transmit, and maintain ePHI. As defined by the Security Rule,
the term ``electronic media'' \334\ encompasses both (1) electronic
storage material on which data is or may be electronically recorded;
and (2) transmission media used to exchange information already in
electronic storage media. It specifically excludes certain
transmissions, such as those of paper, via facsimile (``fax''), and
voice, via telephone, from being considered transmissions via
electronic media if the information being exchanged did not exist in
electronic form immediately before the transmission.
---------------------------------------------------------------------------
\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.
\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
[[Page 922]]
transmissions via fax, and of voice, via telephone, from transmissions
via electronic media, nor does the definition take into consideration
new and emerging technologies. Accordingly, the Department believes
that it is appropriate to reconsider this definition.
---------------------------------------------------------------------------
\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. See Voice Over internet
Protocol (VoIP), Federal Communications Commission, https://www.fcc.gov/general/voice-over-internet-protocol-voip.
\341\ A 2022 report by the Federal Communications Commission
stated that the ``number of fixed retail switched-access lines
declined over the past three years at a compound annual rate of
12.3%, while interconnected VoIP subscriptions increased at a
compound annual growth rate of 0.7%.'' See ``2022 COMMUNICATIONS
MARKETPLACE REPORT,'' Federal Communications Commission, p. 122
(Dec. 30, 2022), https://docs.fcc.gov/public/attachments/FCC-22-103A1.pdf.
---------------------------------------------------------------------------
3. Proposals
The Department proposes to modify the definition of ``electronic
media'' as follows. First, the Department proposes to revise paragraph
(1) of the definition to clarify that electronic media includes not
only media on which data may be recorded, but also media on which data
may be maintained or processed.
Generally, data is either at rest, in transit, or in process (e.g.,
being worked on, in use, being modified in memory, or being
updated).\342\ After the data is no longer in use, it is either
maintained or transmitted. It is especially important for entities to
protect data in process because generally, data must be unencrypted to
be processed, making this a time when it is particularly vulnerable to
a breach or other security incident.\343\ To that end, the Department's
proposal would clarify that the definition includes electronic media
that is used to record, maintain, or process data.
---------------------------------------------------------------------------
\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.
As discussed above, traditional landlines and fax machines are
rapidly being replaced with electronic communication technologies and
mobile technologies that use electronic media. The Security Rule
applies when a regulated entity uses such electronic communication
technologies. Therefore, regulated entities using telephone systems and
fax equipment that transmit ePHI need to apply the Security Rule
safeguards to those technologies.\344\ Accordingly, in paragraph (2),
we propose to revise the description of ``transmission media'' to
recognize that data is transmitted almost exclusively in electronic
form today. The limited exception to this would be data that is
handwritten on paper and hand-delivered or mailed, such that the data
is never on electronic storage material. Additionally, the Department
proposes to include public networks in the examples of transmission
media and to remove the sentence that describes transmissions that are
not considered transmissions via electronic media. By making these
changes, we would reflect technology's evolution since 2013.
---------------------------------------------------------------------------
\344\ The Department previously acknowledged that information
transmitted by a telephone voice response system in response to a
telephone request, and some voice technology digitally produced from
an information system and transmitted by telephone are both covered
by this definition. See 68 FR 8334, 8342 (Feb. 20, 2003); 75 FR
40868, 40874 (July 14, 2010); and 78 FR 5566, 5575 (Jan. 25, 2013).
---------------------------------------------------------------------------
We also propose to make a technical correction to paragraph (2) of
the definition, consistent with a revision made in the 2013 Omnibus
Rule to paragraph (1).\345\ Specifically, the Department proposes to
replace the term ``electronic storage media'' with ``electronic storage
material'' in paragraph (2) to clarify the connection between
definitions of electronic storage material and transmission media. We
neglected to make this change in 2013 when we replaced ``electronic
storage media'' with ``electronic storage material'' in paragraph (1),
which means that paragraph (2) relies on a term that is no longer
defined. This technical correction we propose is consistent with how
the Department has interpreted the definition of transmission media and
the connection between it and electronic storage material since the
change was made in 2013.
---------------------------------------------------------------------------
\345\ 78 FR 5566, 5575-5576 (Jan. 25, 2013).
---------------------------------------------------------------------------
4. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. Whether the proposed modifications accurately capture current
use of electronic media.
b. Whether the proposed modifications allow for future
technological innovation.
c. Whether there are other types of electronic storage material
that the Department should include in the non-exhaustive list of
examples.
d. Whether there are other types of transmission media that the
Department should include in the non-exhaustive list of examples.
B. Section 164.304--Definitions
Section 164.304 includes definitions for key regulatory terms in
the Security Rule. The Department proposes to add ten new defined terms
and to modify the definitions of fifteen existing terms. The proposed
new regulatory terms would be: Deploy, Implement, Electronic
information system, Multi-factor authentication, Relevant electronic
information system, Risk, Technical controls, Technology asset, Threat,
and Vulnerability. The definitions we propose to modify are for the
following terms: Access, Administrative safeguards, Authentication,
Availability, Confidentiality, Information system, Malicious software,
Password, Physical safeguards, Security or Security measures, Security
incident, Technical safeguards, User, and Workstation. Generally, the
Department is proposing to add or modify regulatory terms that would
either clarify how regulated entities should apply the standards and
implementation specifications or modernize the rule to better account
for changes in the environment in which health care is provided.
1. Clarifying the Definition of ``Access''
a. Current Provision and Issues To Address
The Security Rule defines the term ``access'' as the ability or
means necessary to perform a set of activities describing how a user
may interact with a system resource.\346\ These activities are reading,
writing, modifying, communicating data/information, or otherwise using
any component of an information system. The definition applies only to
the Security Rule, not to the Breach Notification Rule or the Privacy
Rule.
---------------------------------------------------------------------------
\346\ 45 CFR 164.304 (definition of ``Access'').
---------------------------------------------------------------------------
The term ``access'' defines the scope of some key regulatory
provisions in the Security Rule. For example, whether a person meets
the definition of a ``user'' is determined based on whether their
access to information or a component of the regulated entity's
information system is authorized.\347\ The definition
[[Page 923]]
of the term ``security incident'' requires consideration of whether a
person attempted to access or accessed information without
authorization.\348\ To determine whether a regulated entity complied
with the administrative safeguard standard for workforce security, the
Department must consider to what extent a regulated entity established
policies and procedures for ensuring that workforce members have
appropriate access to ePHI.\349\
---------------------------------------------------------------------------
\347\ 45 CFR 164.304 (definition of ``User'').
\348\ 45 CFR 164.304 (definition of ``Security incident'').
\349\ 45 CFR 164.308(a)(3)(i); proposed 45 CFR 164.308(a)(9)(i).
---------------------------------------------------------------------------
The current definition is expansive but not fully representative of
how users could interact with information today. As discussed above,
users create, receive, maintain, and transmit information in more ways
now than they did ten years ago. Thus, the Department believes that it
is critical for the Department to consider modifying the definition of
this term to adequately reflect the current electronic environment.
b. Proposal
The Department proposes to expand the list of activities that
should be considered under the term by adding the activities of
``deleting'' and ``transmitting.'' The Department also proposes to
replace ``system resource'' with ``component of an information system''
to rely on an already defined term, ``information system.'' The
proposed modification would clarify that the term includes any and all
components of an information system and an information system as a
whole. Additionally, the Department believes that a component of an
information system better describes how the term access applies today
because it is inclusive of hardware, software, and people, as opposed
to only the inherent capabilities that contribute to performance, such
as system memory and hard disk space.
2. Clarifying the Definition of ``Administrative Safeguards''
a. Current Provision and Issues To Address
Administrative safeguards are administrative actions, policies, and
procedures to manage the selection, development, implementation, and
maintenance (including reviewing and modifying) of security measures to
protect ePHI.\350\ Administrative safeguards also manage the conduct of
the regulated entity's workforce in relation to the protection of ePHI.
Under the Security Rule, there are minor inconsistencies in language
between the definitions of the types of safeguards, which might lead to
uncertainty about how to interpret the terms and lead to unintended
consequences. For example, the definitions of ``administrative
safeguards'' and ``physical safeguards'' use ``are,'' while the
definition of technical safeguards uses ``means.'' \351\
---------------------------------------------------------------------------
\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. 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. 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,
[[Page 924]]
have access on demand to ePHI to carry out their functions.
b. Proposal
Given the increased connectivity of the health care environment,
the Department proposes to clarify the definition of availability by
specifying that availability means the property that data or
information is accessible and usable upon demand by not only an
authorized person, but also an authorized technology asset. In so
doing, the Department is not changing the meaning of availability, but
rather clarifying its scope.
5. Clarifying the Definition of ``Confidentiality''
a. Current Provision and Issues To Address
Similar to the definition of availability, the definition of the
term ``confidentiality'' could be read as limited to the property that
data or information is not made available or disclosed to unauthorized
persons or processes. Read that way, the definition does not reflect
today's health care environment in which data and information may be
accessed through any component of an interconnected electronic
information system.
b. Proposal
The Department proposes to clarify the definition of
confidentiality to specify that it means the property that data or
information is not made available or disclosed to unauthorized persons,
technology assets, or processes.
6. Adding Definitions of ``Deploy'' and ``Implement''
a. Issues To Address
The Security Rule directs regulated entities to implement technical
policies and procedures and assumes that such implementation requires
the installation and configuration of technical safeguards.\353\ OCR is
concerned, based on its investigations and compliance reviews, that
some regulated entities may interpret the regulatory requirement to
implement technical policies and procedures to mean that a regulated
entity is only required to establish written policies and procedures
about technical requirements, but need not then apply effective,
automated technical policies and procedures to all ePHI throughout the
regulated entity's enterprise. For example, in M.D. Anderson, the court
stated that the encryption requirement at 45 CFR 164.312(a)(2)(iv)
requiring a regulated entity to implement a mechanism to encrypt ePHI
does not ``require a covered entity to warrant that its mechanism
provides bulletproof protection of `all systems containing ePHI.' Nor
does it require covered entities to warrant that all ePHI is always and
everywhere `inaccessible to unauthorized users.' '' \354\ Further, the
court added that the requirement does not ``say anything about how
effective a mechanism must be, how universally it must be enforced, or
how impervious to human error or hacker malfeasance it must be.'' \355\
---------------------------------------------------------------------------
\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.
\354\ University of Texas M.D. Anderson Cancer Center, supra
note 258, p. 478.
\355\ Id.
---------------------------------------------------------------------------
Therefore, the Department believes it is necessary to add
definitions that distinguish between implementation of the
administrative and technical safeguards by separately describing how
regulated entities can comply with requirements to implement technical
safeguards and install technical solutions.
b. Proposal
The Department proposes to define the term ``deploy'' to identify a
specific type of ``implementation.'' We believe that the new term and
definition would help to better describe the compliance obligations for
implementation specifications related to the use of technology for
securing the confidentiality, integrity, or availability of ePHI. As
proposed, the definition would require a regulated entity to ensure
that technology is in place, configured for use, and actually in use
and operational throughout the regulated entity. The Department's
proposed use of the term helps illustrate its purpose and utility in
clarifying that policies and procedures, while necessary, are
insufficient to meet requirements for technical safeguards.
For example, the Department is proposing to create a new
requirement for regulated entities to verify that business associates
have deployed technical safeguards--that is, the technology is
configured and operational, not only addressed in policies and
procedures.\356\ In another example, the Department is proposing new
implementation specifications under the access control standard that
would require a regulated entity to deploy technical controls for
relevant electronic information systems so that the system is
configured and applied to limit access to only users and technology
assets that have been granted access rights.\357\ In the automatic
logoff implementation specification for that same standard, the
Department is proposing to replace the requirement to implement
electronic procedures for terminating an electronic session with a
requirement to deploy technical controls that terminate an electronic
session after a period of inactivity.\358\ In each case, the technical
controls must not only be configured for use, but they also must be
applied to and in effect in all ePHI and relevant electronic
information systems.
---------------------------------------------------------------------------
\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. The Department also proposes the term to further
clarify what it means to configure and put technology, technical
controls, and related policies and procedures into effect and be in
use, operational, and function as expected throughout the regulated
entity's enterprise (i.e., deploy) as compared to putting into place
and making effective administrative or physical safeguards. Further,
the Department proposes to expressly clarify that implement also means
that a safeguard must function as expected. Under this proposal, if
adopted, we would not consider a safeguard to be implemented if it is
not functioning in the manner in which it is expected.
For example, a regulated entity's administrative policy requiring
it to take action to prevent infections from malicious software is not
implemented until it is applied throughout the enterprise, meaning that
the entity has ensured that anti-malware protections have been put into
place on all relevant electronic information systems that create,
receive, maintain, or transmit ePHI or that otherwise affect the
confidentiality, integrity, or availability of ePHI throughout the
enterprise.
Similarly, to operationalize such a policy, the regulated entity
must deploy technology assets and/or technical controls to block such
software according to its technical policies and
[[Page 925]]
procedures. In this regard, the proposed term ``deploy'' clarifies that
the technology assets or technical control must be put into place,
configured, and actually work (i.e., function in the manner expected of
the technology or technical control) throughout a regulated entity, in
addition to the relevant policy and procedures being applied across a
regulated entity. To implement a policy and procedure is separate from
the implementation of a technology asset or technical control but in
both cases, the underlying requirement is application across the
enterprise.
7. Adding a Definition of ``Electronic Information System''
a. Issues To Address
The current Security Rule includes explicit requirements for
regulated entities to protect electronic information systems by
implementing policies and procedures to limit physical access to such
systems \359\ and by implementing technical policies and procedures for
electronic information systems that maintain ePHI to allow access to
only persons or technology assets that have been granted access rights
pursuant to 45 CFR 164.308(a)(4).\360\ Further, the physical measures,
policies, and procedures that meet the definition of physical
safeguards are specifically limited to those that protect regulated
entities' electronic information systems and related buildings and
equipment.\361\ And yet, the Security Rule does not explicitly define
this term. Instead, it assumes that the definition is easily understood
to be a subset of information system, a broad term that is not limited
by the boundaries of the Security Rule. The Department believes that
regulated entities would benefit from additional clarity regarding the
definition of this term, given its foundational nature.
---------------------------------------------------------------------------
\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. Proposal
Accordingly, the Department proposes to modify the definition of
``information system,'' to clarify that an information system
``generally'', not just ``normally,'' includes hardware, software,
data, communications, and people. The Department believes this proposed
modification, combined with the existing broad reference to
``resources,'' more accurately reflects the typical components of an
information system and the full extent of resources that are addressed
by the Security Rule. We also propose to remove ``applications'' from
the list of technology assets that are generally included in an
information system because applications are a type of software, making
the inclusion of applications redundant. This proposed modification
would not alter our interpretation that an information system includes
applications.
We use this opportunity to affirm that a technology asset may be
included as part of the information systems of multiple regulated
entities where such regulated entities all have direct management
control over the technology asset. For example, both a health care
provider and a cloud-based EHR vendor have direct management control
over the ePHI in the cloud-based EHR. Accordingly, such ePHI generally
is part of both the information system of the health care provider and
of the cloud-based EHR vendor. Additionally, the EHR that is used to
create, receive, maintain, or transmit ePHI, regardless of whether it
is accessed using software installed on the health care provider's
workstation(s) or an internet browser, generally is also part of the
information system of both entities because both the health care
provider and the vendor have direct management control over the EHR.
9. Modifying the Definition of ``Malicious software''
a. Current Provision and Issues To Address
Persons seeking unauthorized access to data and information are
increasingly sophisticated. Their methods of attempting to gain such
access can take many forms and result in a wide array of harms, as
discussed above. One of the methods they use is through the
introduction of malicious software (also referred to as malware) into
an electronic information system. As the sophistication of bad actors
has increased, so has the variety of types of malicious software that
they use to access electronic information systems. The Security Rule
defines malicious software but limits it to software designed to damage
or disrupt a system. The regulatory text provides only one example of
malicious software in regulatory text--a virus.
b. Proposal
The Department proposes to replace the current definition of
malicious software with one that would be consistent with how
cybersecurity experts define the term today.\362\ Specifically, we
propose to define it to mean software or firmware intended to perform
an unauthorized action or activity that will have adverse impact on an
electronic information system and/or the confidentiality, integrity, or
availability of electronic protected health information. This proposal
would therefore clarify that malicious software could include either
software or firmware and that the negative effects of the malicious
software may not be limited to damaging or disrupting a system. Rather,
effects of the software could be intended to have any type of adverse
impact on an electronic information system and/or the confidentiality,
integrity, or availability of ePHI. The Department also proposes to
include in regulatory text a non-exhaustive list of examples, such as
viruses, worms, Trojan horses, spyware, and some forms of adware, to
assist regulated entities in understanding what constitutes malicious
software.
---------------------------------------------------------------------------
\362\ See NIST definition of ``malware,'' Glossary, Computer
Security Resource Center, National Institute for Standards and
Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/malware.
---------------------------------------------------------------------------
[[Page 926]]
10. Adding a Definition of ``Multi-Factor Authentication'' (MFA)
a. Issues To Address
The Security Rule includes several technical safeguard provisions
that require regulated entities to identify and authenticate persons
accessing information and systems to protect ePHI. Section
164.312(a)(2)(1) includes the standard that requires a regulated entity
to implement technical policies and procedures that limit access to
ePHI to only those persons or software programs that have been granted
access rights, while 45 CFR 164.312(d)(2), the standard for person or
entity authentication, requires a regulated entity to implement
procedures to verify that a person seeking access to ePHI is the one
claimed.
Historically, regulated entities relied on combinations of
usernames and passwords to identify users and authenticate users to the
system. We recognize that such combinations are insufficient to secure
sensitive information and that more sophisticated mechanisms for doing
so have been developed. As a best practice for managing cyber threats,
most cybersecurity frameworks, including those discussed above,
recommend that organizations adopt solutions that rely on multiple
factors to identify and authenticate users. For example, the HHS 405(d)
Program's ``Health Industry Cybersecurity Practices: Managing Threats
and Protecting Patients'' \363\ recommends a layered approach to cyber
defense (i.e., if a first layer is breached, a second exists to prevent
a complete breach).\364\ It further provides that MFA as a source of
identity and access security control is an important means to control
access to infrastructure and conduct proper change management
control.\365\ The Department's CPGs \366\ identify MFA as an essential
goal and a critical, additional layer of security for the protection of
assets and accounts that are directly accessible from the
internet.\367\ The Department has also explained in guidance that weak
authentication processes leave organizations vulnerable to intrusion,
while effective authentication ensures that only authorized entities
may access information systems and data.\368\ Additionally, CISA has
issued recommendations for implementing MFA, specifically MFA solutions
that are phishing resistant to protect against disclosures of
authentication data to a bad actor.\369\
---------------------------------------------------------------------------
\363\ ``Health Industry Cybersecurity Practices: Managing
Threats and Protecting Patients,'' supra note 16.
\364\ Id. at 15.
\365\ Id.
\366\ ``Cybersecurity Performance Goals,'' supra note 18.
\367\ Id.
\368\ See ``HIPAA and Cybersecurity Authentication,''
Cybersecurity Newsletter, Office for Civil Rights, U.S. Department
of Health and Human Services (June 2023), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-june-2023/index.html.
\369\ Id. (citing ``Implementing Phishing-Resistant MFA,''
Cybersecurity & Infrastructure Security Agency, U.S. Department of
Homeland Security (Oct. 2022), https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf); NIST also has issued draft defined characteristics for
phishing-resistant authenticators. See David Temoshok, et al.,
``Digital Identity Guidelines,'' NIST Special Publication 800-63-4
2pd (Second Public Draft), National Institute of Standards and
Technology, U.S. Department of Commerce, p. 36 (Aug. 21, 2024),
https://csrc.nist.gov/pubs/sp/800/63/4/2pd.
---------------------------------------------------------------------------
b. Proposal
The Department proposes to define the term ``Multi-factor
authentication'' to provide regulated entities with a specific level of
authentication for accessing relevant electronic information
systems.\370\ Regulated entities would be required to apply this
proposed definition when implementing the proposed rule's specific
requirements for authenticating users' identities through verification
of at least two of three categories of factors of information about the
user. The proposed categories would be:
---------------------------------------------------------------------------
\370\ See proposed 45 CFR 164.312(f)(2)(ii).
---------------------------------------------------------------------------
Information known by the user, including but not limited
to a password or personal identification number (PIN).
Item possessed by the user, including but not limited to a
token or a smart identification card.
Personal characteristic of the user, including but not
limited to fingerprint, facial recognition, gait, typing cadence, or
other biometric or behavioral characteristics.
MFA relies on the user presenting at least two factors.
Authentication that relies on multiple instances of the same factor,
such as requiring a password and PIN, is not MFA because both factors
are ``something you know.'' \371\ For example, where MFA is deployed,
users could seek access by entering a password. However, without the
entry of at least a second factor such as a token \372\ or smart
identification card, the user is not granted access and the password is
useless by itself. Cybercriminals seeking access to MFA-protected
information systems require significantly more resources to launch the
attack because there are multiple data points required to succeed.\373\
---------------------------------------------------------------------------
\371\ See ``HIPAA and Cybersecurity Authentication,'' supra note
368 (citing David Temoshok, et al., ``Digital Identity Guidelines,''
NIST Special Publication 800-63-4 (Initial Public Draft), National
Institute of Standards and Technology, U.S. Department of Commerce,
p. 17 (Dec. 2022), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.ipd.pdf).
\372\ NIST defines ``token'' as ``a portable, user-controlled,
physical device (e.g., smart card or memory stick) used to store
cryptographic information and possibly also perform cryptographic
functions.'' See NIST definition of ``token,'' Glossary, Computer
Security Resource Center, National Institute of Standards and
Technology, U.S. Department of Commerce (citing Elaine Barker, et
al., ``Recommendation for Key Management: Part 2--Best Practices for
Key Management Organizations,'' NIST Special Publication 800-57,
Part 2, Revision 1, National Institute of Standards and Technology,
U.S. Department of Commerce (May 2019)), https://csrc.nist.gov/
glossary/term/
token#:~:text=NIST%20SP%20800%2D63%2D3%20under%20Token,possibly%20als
o%20perform%20cryptographic%20functions.
\373\ Letter from NCVHS Chair Jacki Monson (2022), supra note
123, p. 7.
---------------------------------------------------------------------------
The Department proposes that the personal characteristics that
could be used as factors would include both physical characteristics,
such as fingerprints or facial identifiers, and behavioral
characteristics, such as a user's gait or typing cadence.\374\
---------------------------------------------------------------------------
\374\ See ``Digital Identity Guidelines: Authentication and
Lifecycle Management'', NIST Special Publication 800-63B, National
Institute of Standard and Technology, section 5.3.3, Use of
Biometrics, (Oct. 16, 2023), https://pages.nist.gov/800-63-3/sp800-63b.html#sec5. We recognize that some of the example characteristics
may not satisfy today's standards; however, the Department
anticipates that they may in the future and proposes that they be
included as examples such that regulated entities will be permitted
to use them when the relevant standards are updated to allow for
such use.
---------------------------------------------------------------------------
11. Clarifying the Definition of ``Password''
a. Current Provision and Issues To Address
The Security Rule currently defines ``password'' as confidential
authentication information composed of a string of characters.\375\ The
definition provides no further regulatory instruction on what
constitutes a ``character'' for purpose of compliance.
---------------------------------------------------------------------------
\375\ 45 CFR 164.304 (definition of ``Password'').
---------------------------------------------------------------------------
b. Proposal
The Department proposes to add examples to the definition to
further clarify what constitutes a character, and adds ``such as
letters, numbers, spaces, and other symbols'' to the existing
definition. The Department believes that regulatory examples would
provide necessary context for regulated entities that deploy safeguards
involving passwords.
[[Page 927]]
12. Clarifying the Definition of ``Physical Safeguards''
a. Current Provision and Issues To Address
``Physical safeguards'' encompass the physical measures, policies,
and procedures that protect a regulated entity's electronic information
systems and related buildings and equipment from natural and
environmental hazards, and unauthorized intrusion. As discussed within
the definition of administrative safeguards, the Department believes
that it is necessary to reduce minor inconsistences in language between
the definitions of the types of safeguards. Additionally, the
definition of physical safeguards relies on an undefined term
(``buildings''), despite the existence of a defined term
(``facilities'') that has an equivalent meaning.
b. Proposal
The Department proposes to clarify that the policies and procedures
referred to in the definition are those that specifically are related
to physical measures, and to replace ``buildings'' with ``facilities''
because facility is a defined term under the Security Rule and has an
equivalent meaning.\376\ The Department intends and has always intended
the physical safeguards to apply to any location where a regulated
entity might possess ePHI, including the physical premises and interior
and exterior of a building, and any location that might affect the
confidentiality, integrity, or availability of ePHI. Additionally,
given the mobility of technology today, including workstations that may
access ePHI, we believe it would be more appropriate to use the term
facility to make clear that the physical safeguards are to apply
throughout the premises of the regulated entity. For the same reasons
discussed above, we also propose to clarify that the physical
safeguards serve to protect relevant electronic information systems, as
we propose to define the term elsewhere in this NPRM, rather than all
electronic information systems. Further, the Department proposes to
better standardize the administrative, physical, and technical
safeguard requirements by using defined terms where they exist.
---------------------------------------------------------------------------
\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. Proposal
The Department proposes to add and define the term ``relevant
electronic information system'' to mean an electronic information
system that creates, receives, maintains, or transmits ePHI or that
otherwise affects the confidentiality, integrity, or availability of
ePHI. We believe that distinguishing between a relevant electronic
information system and an electronic information system, as proposed,
would further clarify the scope of regulated entities' compliance
obligations, including the obligation of regulated entities to
understand the relationship between their various electronic
information systems and the confidentiality, integrity, and
availability of ePHI.
The Department believes it is important to clarify that the
requirements of the Security Rule do not only apply to electronic
information systems that create, receive, maintain, or transmit ePHI.
After all, cybercriminals may be able to access ePHI by leveraging
vulnerabilities in some electronic information systems that do not
themselves create, receive, maintain, or transmit ePHI where such
information systems are connected to or otherwise affect electronic
information systems that do create, receive, maintain, or transmit
ePHI. For example, while a payment processing system used in a covered
entity's food and beverage outlets or gift shops may not create,
receive, maintain, or transmit ePHI, it may affect the confidentiality,
integrity, or availability of ePHI in certain circumstances, such as
where such systems are connected to the same network as servers that
contain ePHI.\378\ Accordingly, we would interpret an electronic
information system as otherwise affecting the confidentiality,
integrity, or availability of ePHI if it is insufficiently segregated
physically and electronically from an electronic information system
that creates, receives, maintains, or transmits ePHI or one that
otherwise affects the confidentiality, integrity, or availability of
ePHI.
---------------------------------------------------------------------------
\378\ See, e.g., Steve Alder, ``$8.9 Million Banner Health Data
Breach Settlement Gets Final Approval,'' The HIPAA Journal (Apr. 27,
2020), https://www.hipaajournal.com/8-9-million-banner-health-data-breach-settlement-gets-final-approval/(describing a settlement to
cover claims stemming from an attack on a health system's payment
processing system used in the food and beverage outlets of its
hospitals).
---------------------------------------------------------------------------
An electronic information system would also fit the category of
``otherwise affecting'' if it contains information that relates to an
electronic information system that creates, receives, maintains, or
transmits ePHI or to another electronic information system that
otherwise affects the confidentiality, integrity, or availability of
ePHI. For example, a compromised electronic information system used to
provide administrative functions, such as user authentication or
management of storage area network infrastructure, that does not
contain ePHI may allow unauthorized access to ePHI (affecting the
confidentiality of ePHI) or disruption of storage configuration data
(affecting the integrity and availability of ePHI). An electronic
information system that is not connected to a covered health care
provider's EHR but that maintains user IDs and passwords for the EHR
also may not create, receive, maintain, or transmit ePHI; however, the
confidentiality, integrity, or availability of the ePHI in the EHR
would be affected if an unauthorized person gained access to that
electronic information system. And the same is true for an electronic
information system that contains the decryption keys for a regulated
entity's encryption algorithms. Thus, it is important that
administrative, physical, and technical safeguards be implemented not
only for electronic information systems that create, receive, maintain,
or transmit ePHI, but also for electronic information systems that
otherwise affect the confidentiality, integrity, or availability of
ePHI.
[[Page 928]]
14. Adding a Definition of ``Risk''
a. Issues To Address
The Security Rule does not currently include a definition for the
term ``risk.'' The Department considered defining it when it first
promulgated the final rule in 2003, but declined to do so because it
determined that the term was commonly understood.\379\ However, the
Department now believes that the lack of a definition may affect the
clarity of some key requirements for regulated entities. Such
requirements include conducting a risk analysis to assess the potential
risks and vulnerabilities to the confidentiality, integrity, and
availability of ePHI held by the regulated entity \380\ and
implementing security measures sufficient to reduce risks and
vulnerabilities to a reasonable and appropriate level to comply with
the general rules at 45 CFR 164.306(a).\381\
---------------------------------------------------------------------------
\379\ 63 FR 8334, 8340 (Feb. 20, 2003).
\380\ 45 CFR 164.308(a)(1)(i)(A).
\381\ 45 CFR 164.308(a)(1)(i)(B). Section 164.306(a) requires
regulated entities to comply with four general requirements to
protect ePHI.
---------------------------------------------------------------------------
One of the ways NIST defines the term is as ``a measure of the
extent to which an entity is threatened by a potential circumstance or
event, and typically a function of: (i) the adverse impacts that would
arise if the circumstance or event occurs; and (ii) the likelihood of
occurrence.'' \382\ This and other NIST definitions serve as helpful
references for the Department when considering how to define the term
within the rule.
---------------------------------------------------------------------------
\382\ See NIST definition of ``risk,'' Glossary, Computer
Security Resource Center, National Institute of Standards and
Technology, U.S. Department of Commerce (citing William Newhouse, et
al., ``Multifactor Authentication for E-Commerce,'' NIST Special
Publication 1800-17, National Institute of Standards and Technology,
U.S. Department of Commerce (July 2019)), https://csrc.nist.gov/glossary/term/risk.
---------------------------------------------------------------------------
b. Proposal
The Department proposes to define ``risk'' as the extent to which
the confidentiality, integrity, or availability of ePHI is threatened
by a potential circumstance or event. The Department believes that
defining the term would clarify several existing and proposed
provisions of the Security Rule, such as the factors regulated entities
must consider when determining the security measures they will
implement \383\ and the importance and purpose of conducting the
required risk analysis.\384\
---------------------------------------------------------------------------
\383\ 45 CFR 164.304(b)(2)(iv).
\384\ 45 CFR 164.308(a)(1)(ii)(A); proposed 45 CFR
164.308(a)(2)(i).
---------------------------------------------------------------------------
15. Clarifying the Definitions of ``Security or Security Measures'' and
``Security Incident''
a. Current Provision and Issues To Address
The Security Rule defines ``security or security measures'' as
encompassing all of the administrative, physical, and technical
safeguards in an information system.\385\ The definition implies that
the safeguards must be part of the information system, as opposed to
something that may be applied or done to a system to protect the
confidentiality, integrity, and availability of ePHI.
---------------------------------------------------------------------------
\385\ 45 CFR 164.304 (definition of ``Security or Security
measures'').
---------------------------------------------------------------------------
The rule also defines ``security incident'' as the attempted or
successful unauthorized access, use, disclosure, modification, or
destruction of information or interference with system operations in an
information system. The existing definition does not make clear that a
security incident may result from two types of behaviors--those related
to attempted or successful but unauthorized access, use, disclosure,
modification, or destruction of information in an information system,
and those that are related to the attempted or successful unauthorized
interference with system operations in an information system. In other
words, a security incident may directly touch upon information in a
system or interfere with the operations of the system itself. The
Department believes that it is necessary to clearly convey the distinct
types of incidents to regulated entities to ensure that regulated
entities implement and deploy safeguards that address both concerns.
b. Proposal
The Department proposes to modify the definition of ``security or
security measures'' to clarify that security or security measures may
not only exist in information systems but may also be applied to
information systems.\386\ This clarification would better reflect the
multi-layered approach to cybersecurity recommended by experts to
address the concerns facing regulated entities today. For example, a
regulated entity may determine that it is necessary to apply access
controls and encryption mechanisms through an external mechanism, such
as added firewall technology,\387\ that is applied to the system,
rather than technical controls that are embedded within the system or
components of the system. The Department believes that the proposed
definition would provide a more complete instruction.
---------------------------------------------------------------------------
\386\ 45 CFR 164.304 (definition of ``Security or Security
measures'').
\387\ See NIST definition of ``firewall,'' Glossary, Computer
Security Resource Center, National Institute of Standards and
Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/firewall.
---------------------------------------------------------------------------
The Department proposes to reorganize the definition of ``security
incident'' into two numbered paragraphs to delineate the two separate
categories of security incidents. We also propose to clarify that in
both instances, the definition applies when the described action
affects an information system and regardless of whether an attempt to
affect the information in the system or interfere with system
operations is successful or not.
16. Adding Definitions of ``Technical Controls''
a. Issues To Address
Throughout the technical safeguards provisions in 45 CFR 164.312,
the Department directs regulated entities to implement technical
policies and procedures. The court in M.D. Anderson interpreted
technical policies and procedures as written policies and procedures on
technical matters.\388\ This interpretation does not reflect the
Department's intent for technical safeguards to include policies and
procedures that rely on technology or technological solutions for
implementation.\389\ We believe that the court's interpretation could
have significant consequences for the confidentiality, integrity, and
availability of ePHI.
---------------------------------------------------------------------------
\388\ See generally University of Texas M.D. Anderson Cancer
Center, 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
[[Page 929]]
required to deploy technical safeguards across its enterprise by, among
other things, configuring and using technical mechanisms in the
hardware, software, and firmware components of its relevant electronic
information systems to protect ePHI and electronic information systems
that create, receive, maintain, or transmit ePHI or that otherwise
affect the confidentiality, availability, or integrity of ePHI.
17. Modifying the Definition of ``Technical Safeguards''
a. Current Provision and Issues To Address
The current definition of ``technical safeguards'' includes the
technology and policy and procedures for its use that protect ePHI and
control access to it.\390\ As discussed above, the Department believes
that there is an immediate need to modernize and update the definition
to better reflect the role technology plays in protecting ePHI and the
technical components of information systems, versus the role of
policies and procedures. This would complement our effort to clarify
the relationship between technology and the implementation of technical
policies and procedures.
---------------------------------------------------------------------------
\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. In so doing, we would clarify which Security Rule requirements
apply to all of the components of electronic information systems as
opposed to those that apply only to certain components, and which
requirements apply to each particular components and which apply to the
entire electronic information system.
For example, understanding the risks and vulnerabilities to a
regulated entity's ePHI requires a thorough understanding of the
components of its electronic information systems, the electronic
information systems themselves, how they are connected, and how ePHI
moves through those systems. Thus, by requiring a regulated entity to
conduct an inventory of its technology assets and to create a network
map of its electronic information systems, we clarify that a regulated
entity is obligated to consider not only its electronic information
systems as a whole, but also the components within those electronic
information systems and their functions.
19. Adding a Definition of ``Threat''
a. Issues To Address
Addressing threats to the confidentiality, integrity, and
availability of ePHI is a key function of the Security Rule, but the
rule does not define ``threat.'' The concept of threat also underlies
the Department's proposed definition of ``risk'' defined above and
forms the basis of a key proposed implementation specification
associated with the standard for risk analysis.\391\
---------------------------------------------------------------------------
\391\ Proposed 45 CFR164.308(a)(2)(ii)(A)(2).
---------------------------------------------------------------------------
b. Proposal
The Department proposes to define the term ``threat'' to mean any
circumstance or event with the potential to adversely affect the
confidentiality, integrity, or availability of ePHI. This proposal is
similar to NIST's varying definitions of threat, edited to apply
specifically to health care and the type of information addressed by
the Security Rule.\392\ Under this proposal, we would construe the term
to apply broadly to include threats caused by, or existing because of,
a variety of circumstances that specifically could affect the security
of ePHI. Hackers, malicious insiders, and malicious software are
examples of threat sources.
---------------------------------------------------------------------------
\392\ See NIST definition of ``threat,'' Glossary, Computer
Security Resource Center, National Institute of Standards and
Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/threat.
---------------------------------------------------------------------------
20. Clarifying the Definition of ``User''
a. Current Provision and Issues To Address
The Department first defined the term ``person'' in the HIPAA Rules
as part of the 2003 ``Civil Money Penalties: Procedures for
Investigations, Imposition of Penalties, and Hearings'' interim final
rule to distinguish a ``natural person'' who could testify in the
context of administrative proceedings from an ``entity'' (defined
therein as a ``legal person'') on whose behalf a person would
testify.\393\ Although they were both published in 2003, the interim
final rule was published two months after the Security Rule. Thus, when
the Security Rule was published in 2003, it was necessary to specify
that the term ``user'' included both natural persons and entities, but
we believe that this is no longer the case because the current
definition of ``person'' includes natural persons as well as
entities.\394\
---------------------------------------------------------------------------
\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,
[[Page 930]]
exploitable vulnerabilities exist across many components of IT
infrastructures including, but not limited to, servers, desktops,
mobile device operating systems, web software, and firewalls.\397\ To
mitigate against intrusions and hacking threats, the Department has
recommended that regulated entities install vendor patches, make
software updates, and monitor sources of cybersecurity alerts
describing new vulnerabilities, such as the NIST National Vulnerability
Database \398\ and CISA's Known Exploited Vulnerabilities Catalog.\399\
---------------------------------------------------------------------------
\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. Current Provision and Issues To Address
The Department currently defines the term ``workstation'' to mean
an electronic computing device and provides the examples of technology
that dominated the health care environment in 2003 and 2013, such as a
laptop, desktop computer, and other device that performs similar
functions, and electronic media stored in its immediate
environment.\404\ Workstations are essential for workforce members to
perform their assigned functions, such as clinicians entering an
individual's health history and treatment plan or billing staff
preparing claims. Workstations are one of the key entry points for
users to access a regulated entity's information systems. Thus, the
Security Rule contains provisions requiring that regulated entities
secure not only their information systems, but also individual
workstations.\405\ However, as discussed above, the health care
environment has changed. It now includes both the physical and virtual
environment and is replete with mobile devices and other types of
devices that may serve as multi-functional workstations. Clinicians and
other workforce members often rely on smart phones, smart watches,
tablets, laptops, and even personal digital assistants, among other
devices. These devices have proliferated, and so has their ability to
perform a wide variety of functions with increasing sophistication. The
Department believes that it is necessary to update the definition to
reflect the evolved nature of the landscape.
---------------------------------------------------------------------------
\404\ 45 CFR 164.304 (definition of ``Workstation'').
\405\ See, e.g., 45 CFR 164.310(b) and (c).
---------------------------------------------------------------------------
b. Proposal
In recognition of this changed environment, the Department proposes
to modify the definition of workstation to provide additional examples
of what constitutes a workstation. Specifically, we propose to add the
examples of a server, virtual device, and a mobile device such as a
smart phone or tablet. Virtual devices could include a virtual medical
device, virtual server, or virtual desktop computer. The proposed
definition also would clarify that technology properly considered as a
``workstation'' is not limited to the proposed regulatory examples.
23. Request for Comment
The Department requests comment on all the foregoing proposed
definitions, including any benefits, drawbacks, or unintended
consequences. We also request comment on the following considerations
in particular:
a. Whether any of the proposed definitions would be problematic for
regulated entities or result in unintended adverse consequences. If so,
please explain.
b. Whether the Department should consider an alternative definition
for any terms the Department proposes to define in the rule. If the
answer is yes, please propose such an alternative definition and a
reference or supporting rationale.
c. Whether the Department should define any additional terms within
the rule. If the answer is yes, please propose such additional terms
and definitions, along with any reference or supporting rationale.
d. With respect to the definitions of ``information system'' and
``electronic information system,'' the extent of a covered entity's
direct management control over applications in cloud computing
environments, such as a cloud-based EHR system.
e. With respect to the definitions of ``information system'' and
``electronic information system,'' the extent of a business associate's
direct management control over applications in cloud computing
environments, where the business associate is the cloud service
provider.
f. Whether defining the term ``technical controls'' and adding it
to the definition of ``technical safeguards'' would more clearly
explain the requirements of 45 CFR 164.312.
g. Whether defining ``implement'' and ``deploy'' as we propose
would more clearly explain the differences between what is expected of
regulated entities with respect to administrative and physical
safeguards and technical safeguards. To the extent that the proposals
would not clarify the differences, please provide alternative
solutions.
C. Section 164.306--Security Standards: General Rules
1. Current Provisions
Section 164.306 applies to regulated entities and includes the
general rules for security standards. Generally, paragraph (a) codifies
HIPAA statutory requirements for safeguarding ePHI.\406\ Under these
rules, regulated entities are required to do all of the following:
---------------------------------------------------------------------------
\406\ See 42 U.S.C. 1320d-2(d).
---------------------------------------------------------------------------
Ensure the confidentiality, integrity, and availability of
all ePHI the regulated entity creates, receives, maintains, or
transmits.\407\
---------------------------------------------------------------------------
\407\ See 42 U.S.C. 1320d-2(d)(2)(A).
---------------------------------------------------------------------------
Protect against reasonably anticipated threats or hazards
to the security or integrity of such information.\408\
---------------------------------------------------------------------------
\408\ See 42 U.S.C. 1320d-2(d)(2)(B)(i).
---------------------------------------------------------------------------
Protect against any reasonably anticipated uses or
disclosures of such information not permitted by the Privacy Rule.\409\
---------------------------------------------------------------------------
\409\ See 42 U.S.C. 1320d-2(d)(2)(B)(ii).
---------------------------------------------------------------------------
Ensure that workforce members comply with the Security
Rule.\410\
---------------------------------------------------------------------------
\410\ See 42 U.S.C. 1320d-2(d)(2)(C).
---------------------------------------------------------------------------
Paragraph (b) of this section permits regulated entities to
determine the most
[[Page 931]]
appropriate security measures for protecting ePHI and their information
systems. Accordingly, 45 CFR 164.306(b)(1) permits regulated entities
to use any security measures to reasonably and appropriately implement
the standards and implementation specifications of the Security Rule,
while 45 CFR 164.306(b)(2) contains the factors that regulated entities
are to consider when deciding which security measures to use. This
paragraph furthers the aim of HIPAA's requirement for the security
standards to take into account certain factors by providing for their
consideration by regulated entities.\411\ Accordingly, 45 CFR
164.306(b)(2) directs regulated entities to take these factors into
account when determining the manner in which they will comply with the
security standards and implementation specifications.
---------------------------------------------------------------------------
\411\ The factors are: (1) the technical capabilities of records
systems used to maintain health information; (2) the costs of
security measures; (3) the need for training; (4) the value of audit
trails in computerized record systems; and (5) the needs and
capabilities of small and rural health care providers. See 42 U.S.C.
1320d-2(d)(1)(A)(i)-(v).
---------------------------------------------------------------------------
Section 164.306(c) requires regulated entities to comply with the
administrative, physical, and technical safeguard standards in sections
45 CFR 164.308, 164.310, and 164.312 respectively, and with standards
for organizational requirements and policies, procedures, and
documentation requirements in sections 45 CFR 164.314 and 164.316. This
provision is followed by paragraph (d), which explains that regulated
entities are required to implement a specific implementation
specification if described as ``required.'' If the implementation
specification is described as ``addressable,'' regulated entities are
required to implement the implementation specification if it is
reasonable and appropriate to do so; or, if it is not reasonable and
appropriate, document why and implement an equivalent alternative
measure.
Finally, the maintenance provision at 45 CFR 164.306(e) requires
regulated entities to review and modify security measures implemented
under the Security Rule as needed to continue providing reasonable and
appropriate protection of ePHI. It also requires regulated entities to
update documentation of such security measures in accordance with the
requirements for documentation at 45 CFR 164.316(b)(2)(iii).
2. Issues To Address
We believe that we can improve consistency in language between this
section and other Security Rule provisions and better align this
section with statutory terms and intent. For example, we are concerned
that regulated entities are misinterpreting 45 CFR 164.306(a) to apply
the requirements of the Security Rule to only some ePHI, rather than
all ePHI. This interpretation could lead to inadequate protection of
ePHI and relevant electronic information systems.\412\ We also believe
that consistency in language facilitates clear understanding and less
ambiguity about how regulated entities must apply Security Rule
standards.
---------------------------------------------------------------------------
\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. The current regulation's framework in 45 CFR 164.306(b) lacks
any express factor that would require an evaluation of the
effectiveness of the security measures in supporting the resiliency of
the regulated entity.
---------------------------------------------------------------------------
\413\ 68 FR 8334, 8343 (Feb. 20, 2023).
---------------------------------------------------------------------------
The Department has explained in regulation and guidance the
difference between required and addressable implementation
specifications. The meaning of ``required'' is clear. Regarding
``addressable,'' we previously explained that its purpose is to provide
regulated entities flexibility with respect to implementation
compliance.\414\ We also previously explained that a regulated entity
must assess whether a given addressable implementation specification is
a reasonable and appropriate security measure to apply within its
environment, and if it is, the regulated entity must implement the
addressable implementation specification.\415\ However, the Department
remains concerned that regulated entities believe that flexibility
overrides the need for them to protect all ePHI and do not uniformly
treat addressable implementation specifications as needing to be met if
they are reasonable and appropriate. OCR's enforcement experience and
interaction with regulated entities causes us to believe that
``addressable'' is misunderstood to be optional, leading regulated
entities to choose not to adopt the implementation specification, even
when it would be reasonable and appropriate for them to do so.\416\
---------------------------------------------------------------------------
\414\ See ``What is the difference between addressable and
required implementation specifications in the Security Rule?,''
Office for Civil Rights, U.S. Department of Health and Human
Services, HIPAA FAQ #2020 (Dec. 28, 2022), https://www.hhs.gov/hipaa/for-professionals/faq/2020/what-is-the-difference-between-addressable-and-required-implementation-specifications/index.html.
\415\ See 45 CFR 164.306(d)(3); ``What is the difference between
addressable and required implementation specifications in the
Security Rule?,'' supra note 414.
\416\ The Department has consistently attempted to dispel the
notion that addressable implementation specifications are optional.
See, e.g., ``Security 101 for Covered Entities,'' HIPAA Security
Series, Centers for Medicare & Medicaid Services, p. 6 (Nov. 2004,
revised Mar. 2007), https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/security101.pdf?language=es; ``Controlling Access to ePHI: For Whose
Eyes Only?,'' Cybersecurity Newsletter, Office for Civil Rights,
U.S. Department of Health and Human Services (July 14, 2021),
https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-summer-2021/index.html; and ``HIPAA
Security Rule Facility Access Controls--What are they and how do you
implement them?,'' Cybersecurity Newsletter, Office for Civil
Rights, U.S. 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
[[Page 932]]
continue to neglect people and process measures necessary for a
comprehensive security program.\418\ NCVHS also pointed to a continued
failure of regulated entities to develop adequate incident recovery
plans and to assess their vulnerability to cyberattacks grounded in
social engineering.\419\ Finally, NCVHS opined that the current
structure of the Security Rule is inadequate to protect U.S. health
care infrastructure because it does not require regulated entities ``to
adopt the basic building blocks of good security hygiene, or a
documented, reasonable alternative.'' \420\
---------------------------------------------------------------------------
\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.
---------------------------------------------------------------------------
\421\ See 68 FR 8334, 8336 (Feb. 20, 2003).
---------------------------------------------------------------------------
We also believe that the current maintenance requirement in 45 CFR
164.306(e) would benefit from increased specificity in light of the
dramatic transformation of the health IT environment discussed above.
For example, providing the frequency with which regulated entities must
review and update their security measures would improve the security of
ePHI and regulated entities' compliance with the Security Rule. The
Security Rule's maintenance requirement would be further strengthened
by requiring regulated entities to test their security measures to
verify their sufficiency, and by clarifying the Department's
expectations regarding documentation. Regulated entities' lack of
documentation about how they implement security measures makes it
difficult for them to know what security measures they have in fact
implemented and to demonstrate compliance with the requirements of the
Security Rule. Finally, the maintenance requirement in 45 CFR
164.306(e) is not included in or designated as a Security Rule
standard, although it explicitly references the overarching
documentation requirements in 45 CFR 164.316(b)(2)(iii). Thus, there is
overlap between the two sections that may be causing confusion
regarding the obligations of regulated entities to maintain security
measures.
3. Proposals
a. Section 164.306(a)--General Requirements
The Department proposes to expand the introductory language to the
general requirements provision at 45 CFR 164.306(a) to clarify the
extent to which the general requirements apply to the obligations of
regulated entities with respect to ePHI that they create, receive,
maintain, or transmit.
Under the proposal, the Department would clarify that the general
requirements apply to ``all'' ePHI. Additionally, the Department
proposes to move language from paragraph (a)(1) to paragraph (a) to
further emphasize that regulated entities must apply the requirements
of the Security Rule to protect all of the ePHI they create, receive,
maintain, or transmit. We also propose to clarify that ``each''
regulated entity would be required to apply the obligations in
paragraphs (a)(1) through (4) to all ePHI it creates, receives,
maintains, or transmits. The Department believes that this proposal
would stress to regulated entities that each and every covered entity
and business associate would be responsible for ensuring it meets
Security Rule requirements with respect to all ePHI.
The Department believes this proposed change would also help
address issues raised by current interpretations of the Security Rule
that suggest that its plain wording may not require regulated entities
to fully implement each security measure to protect all ePHI. Thus, the
Department's proposed language would clarify that a security measure
must be implemented such that it protects the security of all ePHI and
all information systems that affect the confidentiality, integrity, and
availability of ePHI.
Additionally, the Department proposes to modify the general
requirements of paragraph (a)(2) to require each regulated entity to
protect against any reasonably anticipated threats or hazards to the
confidentiality, integrity, or availability of all ePHI, instead of to
the security or integrity of ePHI. We believe that this proposal would
better align this requirement with the general requirement at 45 CFR
164.306(a)(1), and confidentiality, integrity, and availability are
generally considered the three basic elements of security.\422\
---------------------------------------------------------------------------
\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.
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. To acknowledge the rapid
evolution of technology and increasing threats, the Department proposes
to clarify
[[Page 933]]
paragraph (b)(1) to provide that regulated entities are to apply
reasonable and appropriate security measures to implement the standards
and implementation specifications of the Security Rule. This proposal,
if adopted, would replace the existing paragraph providing for
regulated entities' reasonable and appropriate implementation of
standards and implementation specifications, which could be
misinterpreted to mean that a regulated entity may determine that
implementation itself is unreasonable or inappropriate in some
circumstances. That has never been the case. Thus, the proposed
modification would clarify that implementation is not optional based on
whether a regulated entity believes it is reasonable and appropriate;
to the contrary, a regulated entity is required to implement the
standards and implementation specifications and must adopt reasonable
and appropriate security measures that allow the entity to achieve such
implementation. The proposed clarification would comport more precisely
with the statute, which requires regulated entities to maintain
``reasonable and appropriate'' safeguards.\425\
---------------------------------------------------------------------------
\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 when deciding
whether a particular security measure (e.g., a technical control) is
reasonable and appropriate for implementing a standard and its
associated implementation specifications: the effectiveness of the
security measure in supporting the resiliency of the regulated entity.
A regulated entity would be required to consider this factor, in
addition to the existing factors, for example, when choosing a specific
encryption solution that allows the entity to meet the proposed
requirement to encrypt ePHI, which will help prevent an unauthorized
user from accessing the entity's ePHI; or when developing its security
incident plan or disaster recovery plan, which will help ensure that
the regulated entity can recover data or reestablish data integrity
after a security incident or disaster.
The Department proposes at 45 CFR 164.306(b)(2)(v) to require a
regulated entity to take into account how effectively its application
of a particular security measure to achieve compliance with a standard
and its associated implementation specifications would support its
resiliency in the face of an event that adversely affects the entity.
According to NIST, ``information system resilience'' addresses how well
information systems ``continue to (i) operate under adverse conditions
or stress, even if in a degraded or debilitated state, while
maintaining essential operational capabilities; and (ii) recover to an
effective operational posture in a time frame consistent with mission
needs.'' \426\ Recently, in this era of rising cybercrime, NIST
described ``cyber resiliency'' as ``the ability to anticipate,
withstand, recover from, and adapt to adverse conditions, stresses,
attacks, or compromises on systems that use or are enabled by cyber
resources.'' \427\ Thus, the Department proposes to require a regulated
entity to consider the ability of its implementation of a particular
security measure to aid it in preventing, withstanding, and recovering
from an emergency or other occurrence that affects the confidentiality,
integrity, or availability of ePHI, including a successful security
incident.
---------------------------------------------------------------------------
\426\ Joint Task Force, ``Managing Information Security Risk:
Organization, Mission, and Information System View,'' NIST Special
Publication 800-39, Appendix B, National Institute of Standards and
Technology, U.S. Department of Commerce, p. B-5 (Mar. 2011), https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf.
\427\ Ron Ross, et al., ``Developing Cyber-Resilient Systems: A
Systems Security Engineering Approach,'' NIST Special Publication
800-160, Volume 2, Revision 1, National Institute of Standards and
Technology, U.S. Department of Commerce, p. 1 (Dec. 2021), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf.
---------------------------------------------------------------------------
The Department proposes this new requirement to better enable
regulated entities to ensure the confidentiality, integrity, and
availability of all ePHI that they create, receive, maintain, or
transmit. The general rules require regulated entities to not only
prevent threats and hazards to the confidentiality and integrity of
ePHI, but also to ensure the availability of ePHI, even during a
security incident that has the potential to severely hinder the ability
of a regulated entity to provide health care or to bring it to a
standstill. This new factor would require a regulated entity to
consider whether a particular approach to complying with a standard and
the associated implementation specifications can help it recover from
an emergency or other occurrence, in addition to maintaining operations
throughout the event. The Department proposes this factor to complement
its proposals to strengthen the standards for security incident
procedures \428\ and contingency planning \429\ and proposals for new
standards for patch management \430\ and vulnerability management,\431\
discussed in detail below. If finalized, these proposals would help to
ensure that regulated entities put in place the necessary measures to
implement these standards.
---------------------------------------------------------------------------
\428\ Proposed 45 CFR 164.308(a)(12)(i).
\429\ Proposed 45 CFR 164.308(a)(13)(i).
\430\ Proposed 45 CFR 164.308(a)(4)(i).
\431\ Proposed 45 CFR 164.312(h)(1).
---------------------------------------------------------------------------
The factors contemplate that regulated entities will regularly
evaluate the security measures they have applied to comply with the
standards and implementation specifications based on the technology
available and known risks and vulnerabilities at the time of the
evaluation. The Department expects that when the existing factors are
considered with the factor proposed in this NPRM, a regulated entity
would be required to consider whether a specific technical control has
become sufficiently ubiquitous such that choosing not to adopt it would
be unreasonable.
c. Section 164.306(c)--Standards and Implementation Specifications
To address the Department's concerns regarding the apparent
misunderstanding by regulated entities of ``addressable,'' we propose
to modify 45 CFR 164.306(c) and (d) by collapsing the separate
paragraphs into one paragraph (c) to address both standards and
implementation specifications and to remove the distinction between
``addressable'' and ``required'' implementation specifications.
Instead, proposed paragraph (c), if adopted, would require regulated
entities to comply with both the standards and implementation
specifications. The Department believes that eliminating the
distinction would make clear to regulated entities what has always been
a requirement--that the Security Rule sets a floor for cybersecurity
protections and that its flexibility is in allowing them to choose the
manner in which they meet the standards and implementation
specifications, not whether they meet them. The proposed change also
would be consistent with NCVHS' recommendation to require regulated
entities to meet certain minimum cybersecurity hygiene
requirements.\432\
---------------------------------------------------------------------------
\432\ See Letter from NCVHS Chair Jacki Monson (2022), supra
note 123, p. 5-10.
---------------------------------------------------------------------------
The Department acknowledges that proposing to remove the
addressability distinction is a change from the approach adopted in the
2003 Final Rule. At that time, we explained that the decision to
include addressable implementation specifications was made to provide
additional flexibility to
[[Page 934]]
covered entities.\433\ In this rulemaking, the Department proposes to
strengthen protections and address evolving cybersecurity threats.
While we acknowledge that this proposal would reduce the Security
Rule's flexibility, we believe that it is necessary to do so to achieve
HIPAA's purpose of an efficient and effective health care system that
relies on the secure electronic exchange of ePHI. Importantly, removing
the distinction between required and addressable would not eliminate
all of the Security Rule's flexibility and scalability. Instead, it
would simply clarify for regulated entities where the floor of
protection must lie, and regulated entities must implement solutions
that meet that floor, taking into consideration their needs and
capabilities. For example, a small or rural health care provider must
implement a solution that ensures the protection of ePHI in the manner
required by the Security Rule, but the specific solution that it
chooses would reflect consideration of its particular circumstances,
including available resources. In some cases, a small or rural health
care provider might opt to implement a cloud-based EHR or other
software solution that could reduce the health care provider's need to
separately invest in data storage, backup systems, and IT personnel.
And in other circumstances, a small or rural health care provider might
choose to contract with a third party to provide IT support, rather
than hiring its own workforce members to perform such functions.
---------------------------------------------------------------------------
\433\ See 68 FR 8334, 8344 (Feb. 20, 2003).
---------------------------------------------------------------------------
The Department also proposes to delete the maintenance provision at
45 CFR 164.306(e). Instead, as discussed in greater detail below, we
propose to clearly delineate maintenance implementation specifications
for specific standards, when applicable. We believe this approach would
clarify how maintenance requirements relate to specific security
measures and would remove any ambiguity about the need for regulated
entities to regularly review, test, and modify measures as reasonable
and appropriate. We further discuss maintenance provisions below for
each safeguard.
4. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. Whether removing the distinction between required and
addressable implementation specifications would result in unintended
negative consequences for regulated entities. If so, please explain and
provide a recommendation for how the Department should clarify how
regulated entities are required to implement the security measures
described in the proposed rule.
b. Whether the Department should include other factors in 45 CFR
164.306(b) for regulated entities to consider when selecting the
security measures that they will implement to meet the requirements of
the Security Rule. If so, please explain.
c. Whether the factor proposed by the Department at proposed 45 CFR
164.306(b)(2)(v) would help regulated entities identify reasonable and
appropriate security measures.
d. Whether the Department's proposals sufficiently clarify that a
regulated entity is expected to modify its security measures in
response to changes in the environment in which health care is
provided, including, but not limited to, the adoption of new
technology, the evolution of existing technology, and the emergence of
new threats.
e. Whether the proposals sufficiently take into account the needs
and capabilities of small health care providers and rural health care
providers, as required by the statute. If not, please explain and
include a recommendation for ways that the Department could better
account for such needs and capabilities while adequately ensuring the
confidentiality, integrity, and availability of ePHI that they create,
receive, maintain, or transmit. The recommendations should also take
into consideration the effect of the actions taken by small and rural
health care providers on the ePHI that is created, received,
maintained, or transmitted by other regulated entities with whom small
and rural health care providers interact.
D. Section 164.308--Administrative Safeguards
Section 164.308 of title 45 CFR contains the administrative
safeguards that a regulated entity must implement, consistent with the
general requirements described in 45 CFR 164.306. All of the standards
and implementation specifications found in the Administrative
Safeguards section refer to administrative functions, such as policies
and procedures that must be in place for the management and execution
of security measures.
1. Current Provisions
a. Section 164.308(a)
Section 164.308(a) contains most of the standards and associated
implementation specifications that are categorized as administrative
safeguards. The standards for administrative safeguards are as follows:
Security management process.
Assigned security responsibility.
Workforce security.
Information access management.
Security awareness and training.
Security incident procedures.
Contingency plan.
Evaluation.
The standard for security management process at 45 CFR
164.308(a)(1)(i) requires regulated entities to implement policies and
procedures to prevent, detect, contain, and correct security
violations. The Security Rule directs regulated entities as to how they
are to comply with the standard for security management process through
four implementation specifications. Section 164.308(a)(1)(ii)(A)
requires regulated entities to conduct a risk analysis that accurately
and thoroughly assesses potential risks and vulnerabilities to the
confidentiality, integrity, and availability of ePHI they hold. The
implementation specification for risk management at 45 CFR
164.308(a)(1)(ii)(B) requires regulated entities to implement measures
to reduce risks and vulnerabilities, such as those identified in the
risk analysis, to a reasonable and appropriate level. Under 45 CFR
164.308(a)(1)(ii)(C), regulated entities are required to apply
appropriate sanctions against workforce members who fail to comply with
applicable security policies and procedures, while the implementation
specification for information system activity review at 45 CFR
164.308(a)(1)(ii)(D) requires regulated entities to implement
procedures to regularly review information system activity records.
The standard for assigned security responsibility at 45 CFR
164.308(a)(2) requires regulated entities to identify a security
official who is responsible for the development and implementation of
the policies and procedures that are required by this section. There
are no implementation specifications associated with this standard.
Section 164.308(a)(3)(i) contains the standard for workforce
security and requires regulated entities to implement policies and
procedures to ensure that their workforce members have appropriate
access to ePHI, which includes preventing workforce members who do not
have authorized access from
[[Page 935]]
obtaining it. The implementation specifications associated with this
standard address the need to implement certain procedures regarding
workforce member access to ePHI. Section 164.308(a)(3)(ii)(A) addresses
the implementation of procedures for the authorization and/or
supervision of workforce members who work with ePHI or in locations
where it might be accessed. The implementation specification for
workforce clearance procedure at 45 CFR 164.308(a)(3)(ii)(B) addresses
the implementation of procedures to determine that a workforce member's
access to ePHI is appropriate, while 45 CFR 164.308(a)(3)(ii)(C)
addresses the implementation of procedures for terminating a workforce
member's access to ePHI when their employment or similar arrangement
ends or as required by the regulated entity's workforce clearance
procedures.
Under 45 CFR 164.308(a)(4)(i), the standard for information access
management, a regulated entity is required to implement policies and
procedures for authorizing access to ePHI in a manner that is
consistent with the requirements of the Privacy Rule, that is, only
when such access is appropriate based on the user or recipient's role
(i.e., ``role-based access''). This interpretation is consistent with
the Privacy Rule's standard that limits most uses and disclosures of
PHI to the ``minimum necessary'' to accomplish the purpose of the use
or disclosure.\434\ The standard for information access management has
three implementation specifications: paragraph (a)(4)(ii)(A) requires a
health care clearinghouse that is part of a larger organization to
implement policies and procedures to protect ePHI from unauthorized
access by that organization; paragraph (a)(4)(ii)(B) addresses
implementation of policies and procedures for granting access to ePHI,
for example, through a workstation, program, or other mechanism; and
paragraph (a)(4)(ii)(C) addresses the implementation of policies and
procedures that, based on the regulated entity's access authorization
policies, establish, document, review, and modify a user's right of
access to a workstation, program, or other process.
---------------------------------------------------------------------------
\434\ See 45 CFR 164.502(b) and 164.514(d).
---------------------------------------------------------------------------
Section 164.308(a)(5)(i) contains the standard for security
awareness and training. This standard requires a regulated entity to
implement a security awareness and training program for all workforce
members, including management. There are four associated implementation
specifications that address the need for regulated entities to
implement the following:
Periodic security updates.\435\
---------------------------------------------------------------------------
\435\ 45 CFR 164.308(a)(5)(ii)(A).
---------------------------------------------------------------------------
Procedures for guarding against, detecting, and reporting
malicious software.\436\
---------------------------------------------------------------------------
\436\ 45 CFR 164.308(a)(5)(ii)(B).
---------------------------------------------------------------------------
Procedures for monitoring log-in attempts and reporting
discrepancies.\437\
---------------------------------------------------------------------------
\437\ 45 CFR 164.308(a)(5)(ii)(C).
---------------------------------------------------------------------------
Procedures for creating, changing, and safeguarding
passwords.\438\
---------------------------------------------------------------------------
\438\ 45 CFR 164.308(a)(5)(ii)(D).
---------------------------------------------------------------------------
The standard for security incident procedures at 45 CFR
164.308(a)(6)(i) requires a regulated entity to implement policies and
procedures to address security incidents. The one implementation
specification associated with this standard, 45 CFR 164.308(a)(6)(ii),
requires regulated entities to identify and respond to suspected or
known security incidents; to mitigate, to the extent practicable,
harmful effects of security incidents that are known to the regulated
entity; and to document security incidents and their outcomes.
Under the standard for contingency planning at 45 CFR
164.308(a)(7)(i), a regulated entity is required to establish, and
implement as needed, policies and procedures for responding to an
emergency or other occurrence that damages systems that contain ePHI.
The standard includes five implementation specifications at 45 CFR
164.308(a)(7)(ii). The first, paragraph (a)(7)(ii)(A), requires a
regulated entity to establish and implement procedures to create and
maintain exact copies of ePHI that are retrievable.\439\ Paragraph
(a)(7)(ii)(B) requires a regulated entity to establish, and implement
as needed, procedures to restore any lost data.\440\ Paragraph
(a)(7)(ii)(C) requires a regulated entity to establish, and implement
as needed, procedures to enable continuation of critical business
processes for protecting the security of ePHI while the regulated
entity is operating in emergency mode. Paragraph (a)(7)(ii)(D)
addresses the implementation of procedures for periodic testing and
revision of contingency plans, and paragraph (a)(7)(ii)(E) addresses
the assessment of the relative criticality of specific applications and
data in support of other contingency plan components.
---------------------------------------------------------------------------
\439\ 45 CFR 164.308(a)(7)(ii)(A).
\440\ 45 CFR 164.308(a)(7)(ii)(B).
---------------------------------------------------------------------------
The standard for evaluation at 45 CFR 164.308(a)(8) requires a
regulated entity to periodically perform a technical and nontechnical
evaluation that establishes the extent to which the regulated entity's
security policies and procedures meet the requirements of the Security
Rule. The initial evaluation is to be based upon the standards
implemented under the Security Rule, while subsequent evaluations are
to be conducted in response to environmental or operational changes
affecting the security of ePHI.
b. Section 164.308(b)
Section 164.308(b) contains the administrative safeguards that
apply to the relationships between regulated entities. Specifically, 45
CFR 164.308(b)(1) permits a covered entity to engage a business
associate to create, receive, maintain, or transmit ePHI on the covered
entity's behalf when it obtains satisfactory assurances (consistent
with the organizational requirements for business associate agreements
or other arrangements in 45 CFR 164.314(a)) that the business associate
will appropriately safeguard the ePHI. Similarly, under 45 CFR
164.308(b)(2), a business associate may retain a subcontractor to
create, receive, maintain, or transmit ePHI on its behalf if the
business associate obtains satisfactory assurances through a business
associate agreement or other arrangement that the subcontractor will
appropriately safeguard the information. Section 164.308(b)(3) requires
that the contract or other arrangement be in writing.\441\
---------------------------------------------------------------------------
\441\ 45 CFR 164.308(b)(3).
---------------------------------------------------------------------------
2. Issues To Address
The Security Rule administrative standards are comprehensive, but
our experience has demonstrated that they have been misunderstood by
some regulated entities, especially regarding how compliance with the
standards and implementation specifications must be integrated with the
general requirements in 45 CFR 164.306, including the requirement in 45
CFR 164.306(e) that a regulated entity must review and modify security
measures. Section 164.306 does not explicitly reference specific
security measures, and we are concerned that recent caselaw has
highlighted conditions that may cause regulated entities to
misinterpret regulatory text that connects the maintenance provision at
45 CFR 164.306(e) with the documentation requirements in 45 CFR 164.316
and the administrative safeguards. Through OCR's educational and
enforcement efforts, we also have observed inadequacies in compliance
with security management processes. For example, some regulated
entities have
[[Page 936]]
incorrectly interpreted the standards to not require implementing
administrative safeguards, such as risk analyses, for all relevant
electronic information systems. Some regulated entities have not
documented in writing their policies, procedures, plans, and
analyses.\442\ As discussed above, many mistakenly treated
``addressable'' implementation standards as optional.\443\ Enforcement
experience has shown that regulated entities generally do not perform
all elements of the risk management process that are fundamental to
protecting the confidentiality, integrity, and availability of ePHI and
to cybersecurity more broadly.
---------------------------------------------------------------------------
\442\ See proposed revisions to 45 CFR 164.316 for a more
fulsome discussion of documentation requirements.
\443\ See proposed revisions to 45 CFR 164.306(c) and (d) for a
more fulsome discussion of the distinction between ``required'' and
``addressable'' implementation specifications.
---------------------------------------------------------------------------
In addition, since the Security Rule was issued in 2003 and revised
in 2013, newer, more protective security technology has become widely
available to regulated entities, and best practices for securing
electronic information have evolved. NIST has published numerous
guides, including its recent Cybersecurity Framework 2.0, providing
resources for establishing and implementing policies and practices to
better manage cybersecurity risks.\444\ OCR is drawing upon its
enforcement experience, as well as best practices, guidelines,
processes, and procedures for improving cybersecurity to propose
changes to these standards to better protect ePHI that a regulated
entity creates, receives, maintains, or transmits. We believe that
these proposals would help ensure that regulated entities implement
compliance activities that are consistent with recommendations made by
NIST, the HHS 405(d) program, and standards setting bodies regarding
cybersecurity.
---------------------------------------------------------------------------
\444\ See ``The NIST Cybersecurity Framework (CSF) 2.0,'' supra
note 15.
---------------------------------------------------------------------------
Because business associates are directly liable for compliance with
the Security Rule, in our 2013 Security Rule revisions we did not
require covered entities to implement any additional safeguards to
ensure that their business associate is in fact in compliance.\445\
However, OCR has learned through its enforcement experience that many
covered entities have entrusted ePHI to business associates that are
not employing appropriate safeguards. Some business associates have
such market power that covered entities may believe they have no
alternative to using their services, even if they have concerns about
the safeguards employed by the business associate. The Department is
concerned by the breaches experienced by business associates and the
effects of such breaches on the confidentiality, integrity, and
availability of ePHI.\446\
---------------------------------------------------------------------------
\445\ See 78 FR 5566, 5572-5573 (Jan. 25, 2013) (explaining
reasons for adopting proposal to apply the business associate
provisions of the HIPAA Rules to subcontractors and thus, provides
in the definition of ``business associate'' that a business
associate includes a ``subcontractor that creates, receives,
maintains, or transmits protected health information on behalf of
the business associate'').
\446\ See, e.g., OCR information about the Change Healthcare
cybersecurity incident. ``Change Healthcare Cybersecurity Incident
Frequently Asked Questions,'' U.S. Department of Health and Human
Services (July 30, 2024), https://www.hhs.gov/hipaa/for-professionals/special-topics/change-healthcare-cybersecurity-incident-frequently-asked-questions/index.html.
---------------------------------------------------------------------------
3. Proposals
a. Section 164.308--Administrative Safeguards
Throughout this section, the Department proposes to add explicit
maintenance requirements to certain standards to address concerns that
regulated entities may be misinterpreting the regulatory text that
connects the maintenance provision at 45 CFR 164.306(e) with the
administrative safeguards. These proposals would clarify that a
regulated entity is required to maintain certain security measures, and
that where a regulated entity is required to maintain a particular
security measure, it is required to review and test such measure on a
specified cadence, and to modify the measure as reasonable and
appropriate. Testing of particular security measures, such as technical
controls or policies and procedures, would include verifying that the
security measures work as designed and that workforce members know how
to implement them. For example, written policies and procedures can be
tested through various methods including, but not limited to:
simulating security events that mimic real-world attacks to assess how
effectively employees follow incident response and security procedures;
conducting knowledge assessments after training on policies and
procedures; and reviewing system logs and access records to evaluate
whether policies and procedures governing access to ePHI are being
followed. We would expect a regulated entity to take the results of the
required tests into consideration when determining whether it is
reasonable and appropriate to modify its security measures, as well as
the actions that would be expected of a regulated entity that is
similarly situated based on the results of such tests.
We also propose to modify certain administrative safeguards to
clarify the obligations of a regulated entity to ensure the
confidentiality, integrity, and availability of ePHI by securing its
relevant electronic information systems--that is, its electronic
information systems that create, receive, maintain, or transmit ePHI
and those that otherwise affect its confidentiality, integrity, or
availability--and the technology assets in its relevant electronic
information systems.
b. Section 164.308(a)
The Department proposes to modify the general language at 45 CFR
164.308(a) to clarify the connection between the general rules for
security standards at 45 CFR 164.306, the standards for policies and
procedures and documentation requirements at 45 CFR 164.316, and the
standards for the administrative safeguards under 45 CFR 164.308(a). We
also propose to clarify that regulated entities would be required to
implement all of the administrative safeguards of the Security Rule to
protect the confidentiality, integrity, or availability of all ePHI
that they create, receive, maintain, or transmit. Thus, when read
together, proposed 45 CFR 164.308(a) and 164.316(a) would require that
a regulated entity implement and document, in writing, its
implementation of the administrative safeguards required by the
Security Rule. These requirements set the baseline for administrative
safeguards. Nothing in this NPRM would prevent a regulated entity from
implementing additional administrative safeguards, provided that those
additional safeguards do not conflict with any requirements in the
Security Rule.
The proposed changes are discussed in greater detail below.
c. Section 164.308(a)(1)(i)--Standard: Technology Asset Inventory
We propose to modify 45 CFR 164.308(a)(1) by elevating to standard-
level status the existing implementation specifications for the
standard for security management process at 45 CFR 164.308(a)(1)(ii)(A)
through (D), and deleting the existing standard. Doing so would
highlight the importance of these elements and permit us to add
implementation specifications that detail our expectations for
compliance with those elements. We believe that providing more
specificity in our requirements would help regulated entities better
understand their compliance responsibilities for
[[Page 937]]
safeguarding ePHI. These proposals are consistent with current
guidance, as described below.
In place of the existing standard for security management process,
we propose a standard at 45 CFR 164.308(a)(1)(i) that would require a
regulated entity to conduct and maintain an accurate and thorough
written technology asset inventory and a network map of its electronic
information systems and all technology assets that may affect the
confidentiality, integrity, or availability of ePHI. The inventory
forms the foundation for a fulsome and accurate risk analysis. A
regulated entity must identify its information systems that create,
receive, maintain, or transmit ePHI and all technology assets, as we
propose to define them in 45 CFR 164.304, that may affect ePHI in such
information systems in order to secure them. Regulated entities cannot
understand the risks to the confidentiality, integrity, and
availability of their ePHI without a complete understanding of these
assets. We believe that this proposal would clarify compliance
expectations and provide increased protections for the confidentiality,
integrity, and availability of ePHI. Consistent with practices
previously highlighted in guidance, regulated entities would be
required by this proposal to conduct and maintain an accurate and
thorough written inventory of technology assets.
The standard would also require each regulated entity to determine
the movement of ePHI through, into, and out of its information systems
and to describe such movement in a network map. A regulated entity's
network map would reflect where its technology assets are, for example,
physically located at the regulated entity's worksite, or accessed
through the cloud. As another example, a covered entity might determine
that ePHI is created, received, maintained, or transmitted by one or
more offshore business associates (i.e., persons that are located
outside of the U.S.) for such services as claims processing, call
center staffing, and technical support, activities that inherently
involve ePHI. The technology assets used by the business associate to
create, receive, maintain, or transmit ePHI are not a part of the
covered entity's electronic information system, but do affect the
confidentiality, integrity, or availability of ePHI and so would be
required to be included in the network map of the covered entity.\447\
Such assets would be considered part of the business associate's
electronic information systems and therefore would need to be included
in both its technology asset inventory and network map. Any technology
assets used by the covered entity to create, receive, maintain, or
transmit ePHI to the business associate would need to be accounted for
in both its technology asset inventory and network map. Such technology
assets would not be part of the business associate's technology asset
inventory, but would need to be included on its network map.
---------------------------------------------------------------------------
\447\ See ``Guidance on HIPAA & Cloud Computing,'' Office for
Civil Rights, U.S. Department of Health and Human Services (``A
covered entity (or business associate) that engages a [cloud service
provider (CSP)] should understand the cloud computing environment or
solution offered by a particular CSP so that the covered entity (or
business associate) can appropriately conduct its own risk analysis
and establish risk management policies, as well as enter into
appropriate [business associate agreements.].''), https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html.
---------------------------------------------------------------------------
This proposed standard aligns with the Department's enhanced CPG
for Asset Inventory, which requires that a regulated entity identify
assets to more rapidly detect and respond to potential risks and
vulnerabilities,\448\ and is consistent with NCVHS' recommendation to
require regulated entities to identify where all PHI is stored and to
collect data on applications and systems used by the organization to
create a systems inventory.\449\
---------------------------------------------------------------------------
\448\ ``Cybersecurity Performance Goals,'' supra note 18.
\449\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 5.
---------------------------------------------------------------------------
In 2003, the Department elected not to require regulated entities
to conduct an inventory because we believed that regulated entities
would understand that such an inventory is a vital component of the
risk analysis, making it redundant of other requirements of the
Security Rule.\450\ The Department and NIST have provided extensive
guidance, described below, about how to conduct such inventories as
part of compliance with 45 CFR 164.308. However, nearly 20 years of
enforcement experience indicates that regulated entities routinely
disregard this part of the process. OCR's investigations frequently
find that organizations lack sufficient understanding of where all the
ePHI entrusted to their care is located.\451\
---------------------------------------------------------------------------
\450\ See 68 FR 8333, 8352 (Feb. 20, 2003).
\451\ See ``Making a List and Checking it Twice: HIPAA and IT
Asset Inventories,'' Cybersecurity Newsletter, Office for Civil
Rights, U.S. Department of Health and Human Services (Aug. 25,
2020), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-summer-2020/index.html.
---------------------------------------------------------------------------
Understanding one's environment--particularly how ePHI is created
and enters an organization, how ePHI flows through an organization, and
how ePHI leaves an organization--is crucial to understanding the risks
ePHI is exposed to throughout an organization.\452\ According to the
NIST Cybersecurity Framework 2.0, having a comprehensive understanding
of the organization's assets (e.g., data, hardware, software, systems,
facilities, services, people), suppliers, and related cybersecurity
risks enables a regulated entity to prioritize its efforts consistent
with its risk management strategy and its mission needs.\453\
---------------------------------------------------------------------------
\452\ Id.
\453\ See ``The NIST Cybersecurity Framework (CSF) 2.0,'' supra
note 15, p. 3.
---------------------------------------------------------------------------
The proposed standard would be accompanied by three implementation
specifications. Under the proposed implementation specification for
inventory at proposed 45 CFR 164.308(a)(1)(ii)(A), the regulated entity
would be required to establish a written inventory that contains the
regulated entity's technology assets. Technology assets are components
of an electronic information system, including but not limited to
hardware, software, electronic media, information, and data. The
written inventory would be required to include technology assets that
create, receive, maintain, or transmit ePHI and those that do not but
that may affect the confidentiality, integrity, or availability of
ePHI.\454\ It would also be required to include the identification,
version, person accountable for, and location of each of the assets or
information system components.\455\
---------------------------------------------------------------------------
\454\ Proposed 45 CFR 164.308(a)(1)(ii)(A).
\455\ Id.
---------------------------------------------------------------------------
The proposed implementation specification for network map at
proposed 45 CFR 164.308(a)(1)(ii)(B) would require a regulated entity
to develop a network map that illustrates the movement of ePHI
throughout its electronic information systems, including but not
limited to how ePHI enters and exits such information systems, and is
accessed from outside of such information systems.
Under the proposed implementation specification for maintenance at
proposed 45 CFR 164.308(a)(1)(ii)(C), a regulated entity would be
required to review and update the written inventory of technology
assets and the network map in the following circumstances: (1) on an
ongoing basis, but at least once every 12 months; and (2) when there is
a change in the regulated entity's environment or operations that may
affect ePHI. Such a change in the
[[Page 938]]
regulated entity's environment or operations would include, but would
not be limited to, the adoption of new technology assets; the
upgrading, updating, or patching of technology assets; newly recognized
threats to the confidentiality, integrity, or availability of ePHI; a
sale, transfer, merger, or consolidation of all or part of the
regulated entity with another person; a security incident that affects
the confidentiality, integrity, and availability of ePHI; and relevant
changes in Federal, State, Tribal, or territorial law. For example, a
dissolution or bankruptcy of the regulated entity would require the
regulated entity to review and update its inventory and network map.
For another example, if a State implemented regulations specifying
cybersecurity requirements for all hospitals, these proposed
specifications would require a regulated entity in that State to review
and update its inventory and network map considering implementation of
the State regulations by the regulated entity or other persons whose
activities may affect movement of ePHI throughout its electronic
information systems.\456\
---------------------------------------------------------------------------
\456\ See, e.g., ``New York State Register,'' supra note 14.
---------------------------------------------------------------------------
The proposed standard is consistent with the NIST Cybersecurity
Framework Identify function, Asset Management (ID.AM) category, which
describes inventorying hardware and software and mapping communication
and data flows to create and maintain an asset inventory that can be
used in a risk analysis process. For example, the Cybersecurity
Framework recommends that when creating an asset inventory,
organizations should include all of the following, as applicable:
Hardware assets that comprise physical elements, including
electronic devices and media, that make up an organization's networks
and systems. This may include mobile devices, servers, peripherals
(e.g., printers, USB hubs), workstations, removable media, firewalls,
and routers.
Software assets that are programs and applications that
run on an organization's electronic devices. Well-known software assets
include anti-malicious software tools, operating systems, databases,
email, administrative and financial records systems, electronic
medical/health record systems, and clinical decision support tools,
including those that rely on AI. Though lesser known, there are other
programs important to IT operations and security such as backup
solutions, and other administrative tools that also should be included
in an organization's inventory.
Data assets that include ePHI that an organization
creates, receives, maintains, or transmits on its network, electronic
devices, and media. How ePHI is used and flows through an organization
is important to consider as an organization conducts its risk
analysis.\457\
---------------------------------------------------------------------------
\457\ ``Making a List and Checking it Twice: HIPAA and IT Asset
Inventories,'' supra note 451.
---------------------------------------------------------------------------
Where multiple persons have control over a technology asset, all
persons that have control should include the asset in both their
technology asset inventories and on their network maps. For example,
where a covered entity contracts with a cloud-based EHR vendor, both
the covered entity and the EHR vendor have control over the ePHI in the
EHR. Thus, the ePHI in the EHR and the EHR should be included in the
technology asset inventories and network maps of both the covered
entity and the cloud-based EHR vendor. Where the technology assets are
controlled entirely by another person, such as the servers controlled
by a cloud-based provider of data backup services, the technology
assets would not be considered part of a health care provider's
electronic information systems, and therefore would not have to be
included in its technology asset inventory. However, the data backup
provider would have to be included in the health care provider's
network map.
When creating or maintaining a technology asset inventory that can
aid in identifying risks to ePHI, regulated entities should consider
their technology assets that may not create, receive, maintain or
transmit ePHI, but that may affect technology assets that do so.\458\
Assets within an organization that do not create, receive, maintain, or
transmit ePHI may still present opportunities for intruders to enter
the regulated entity's electronic information systems, which could lead
to risks to the confidentiality, integrity, or availability of an
organization's ePHI. For example, consider a smart device that is
connected to the internet (e.g., connected to the Internet of Things
\459\ (IoT)) and provides access to facilities for maintenance
personnel to control and monitor an organization's heating,
ventilation, and air conditioning (HVAC). Although it may not maintain
or process ePHI, such a device potentially can present serious risks to
the security of ePHI in an organization's information systems.
Unpatched IoT devices with known vulnerabilities, such as weak or
unchanged default passwords installed on a network without firewalls,
network segmentation, or other techniques that deny or impede an
intruder's lateral movement, can provide an intruder with access to an
organization's relevant electronic information systems. The intruder
may then leverage this access to conduct reconnaissance and further
penetrate an organization's network and potentially compromise ePHI.
---------------------------------------------------------------------------
\458\ Id.
\459\ NIST defines the Internet of Things as ``[t]he network of
devices that contain the hardware, software, firmware, and actuators
which allow the devices to connect, interact, and freely exchange
data and information.'' NIST definition of ``Internet of Things,''
Glossary, Computer Security Resource Center, National Institute of
Standards and Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/internet_of_things.
---------------------------------------------------------------------------
The risks and deficiencies OCR has observed in its enforcement
experience persuades us that we must consider adding an express
requirement for a regulated entity to conduct an accurate and thorough
written inventory of its technology assets and create a network map.
d. Section 164.308(a)(2)(i)--Standard: Risk Analysis
After a regulated entity conducts a written inventory of its
technology assets and creates its network map, it is critical for it to
identify the potential risks and vulnerabilities to its ePHI.
Conducting a risk analysis is necessary to adequately protect the
confidentiality, integrity, and availability of ePHI because it
provides the basis for determining the manner in which the regulated
entity will comply with and carry out the other standards and
implementation specifications in the Security Rule.\460\ Basic
questions that a regulated entity would consider when conducting a risk
analysis that is compliant with the Security Rule include: \461\
---------------------------------------------------------------------------
\460\ See ``Guidance on Risk Analysis,'' Office for Civil
Rights, U.S. Department of Health and Human Services (July 22,
2019), https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html?language=es.
\461\ Id.; see also Jeffrey A. Marron, ``Implementing the Health
Insurance Portability and Accountability Act (HIPAA) Security Rule:
A Cybersecurity Resource Guide,'' NIST Special Publication 800-66,
Revision 2, National Institute of Standards and Technology, U.S.
Department of Commerce, p.28-84 (Feb. 2024), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf.
---------------------------------------------------------------------------
Have you identified all the ePHI that you create, receive,
maintain, or transmit?
What are the external sources of ePHI? For example, do
vendors or consultants create, receive, maintain, or transmit ePHI?
What are the human, natural, and environmental threats to
information systems that contain ePHI?
[[Page 939]]
What are the risks posed by legacy devices, including any
risks that would be posed by replacing legacy devices with new ones?
There are numerous methods of performing a risk analysis, and there
is no single method or ``best practice'' that guarantees compliance
with the Security Rule.\462\ The Department has issued multiple
guidance documents and tools for regulated entities to help them
implement risk analyses,\463\ and several versions of its Security Risk
Assessment Tool, a desktop application that walks users through the
process of conducting a risk assessment.\464\ NIST has published
numerous guides for risk assessment over the past two decades,\465\ in
addition to reference materials it has developed in collaboration with
the Department, including a toolkit and a crosswalk between the
Security Rule to NIST Cybersecurity Framework,\466\ and ``how to''
guides on risk analysis.\467\ In February 2024, NIST released a new
guide that provides resources for implementing a Security Rule risk
analysis.\468\ Consistent with previous Department guidance, the guide
describes key elements in a comprehensive risk assessment process, that
include the following:
---------------------------------------------------------------------------
\462\ See ``Guidance on Risk Analysis,'' supra note 460.
\463\ See id.
\464\ See ``Security Risk Assessment Tool,'' Office for Civil
Rights and Office of the National Coordinator for Health Information
Technology, U.S. Department of Health and Human Services (updated
Sept. 5, 2023), https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool.
\465\ See ``HIPAA Security Rule,'' National Institute of
Standards and Technology, U.S. Department of Commerce (Jan. 3, 2011,
updated July 21, 2022), https://www.nist.gov/programs-projects/security-health-information-technology/hipaa-security-rule.
\466\ See ``HIPAA Security Rule Crosswalk to NIST Cybersecurity
Framework,'' Office for Civil Rights, U.S. Department of Health and
Human Services (June 2020), https://www.hhs.gov/guidance/sites/default/files/hhs-guidance-documents//nist-csf-to-hipaa-security-rule-crosswalk-02-22-2016-final.pdf.
\467\ ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\468\ See id.
---------------------------------------------------------------------------
Prepare for the assessment by conducting a technology
asset inventory.\469\ Determine whether ePHI is transmitted to external
third parties, such as cloud service providers or others. The regulated
entity can also examine how access to ePHI is controlled and whether
ePHI is encrypted at rest and in transit. The scope of a risk
assessment should include both the physical boundaries of a regulated
entity's location and a logical boundary that includes any devices or
media that contain ePHI, including electronic networks through which
ePHI is transmitted, regardless of its location.
---------------------------------------------------------------------------
\469\ This component of the assessment would be accomplished
under the NPRM, if adopted, through compliance with the proposed
standard for technology asset inventory at proposed 45 CFR
164.308(a)(1)(i). Under the current Security Rule, we consider the
technology asset inventory to be a component of the standard for
risk analysis.
---------------------------------------------------------------------------
Identify reasonably anticipated threats. The list of
threat events and threat sources should include reasonably anticipated
and probable human and natural incidents that can negatively affect the
regulated entity's ability to protect ePHI. The information gathered
for the technology asset inventory should be used to identify
reasonably anticipated threats to ePHI.
Identify potential vulnerabilities and predisposing
conditions. For any of the various threats identified above to result
in a significant risk, each needs a vulnerability or predisposing
condition that can be exploited. While it is necessary to review
threats and vulnerabilities as unique elements, they are often
considered at the same time. Organizations should consider a given loss
scenario and evaluate both, such as what threat sources might initiate
which threat events or what vulnerabilities or predisposing conditions
those threat sources might exploit to cause an adverse effect. From
this, the regulated entity should develop a list of vulnerabilities
(i.e., flaws or weaknesses) that could be exploited by potential threat
sources.
Determine the likelihood that a threat would exploit a
vulnerability. For each threat event/threat source identified, a
regulated entity should consider: the likelihood that the threat would
occur and the likelihood that an occurred threat would exploit an
identified vulnerability and result in an adverse effect. A regulated
entity might consider assigning a likelihood value (e.g., ``very low,''
``low,'' ``moderate,'' ``high,'' or ``very high'') to each threat/
vulnerability pairing. As an example, the regulated entity may
determine that the likelihood of a phishing attack occurring is very
high and that the likelihood of the event exploiting a human
vulnerability is moderate, resulting in an overall likelihood rating of
high.
Determine the impact of a threat exploiting a
vulnerability. As with likelihood determination, a regulated entity may
choose to express this effect in qualitative terms or use any other
scale that the entity chooses. When selecting an impact rating, the
regulated entity may consider how the threat event can affect the loss
or degradation of the confidentiality, integrity, or availability of
ePHI. Some tangible impacts can be measured quantitatively in terms of
lost revenue, the cost of repairing the system, or the level of effort
required to correct problems caused by a successful threat action.
Other impacts cannot be measured in specific units (e.g., the loss of
public confidence, the loss of credibility, or damage to an
organization's interests), but they can be qualitatively described.
Determine the level of risk to ePHI while considering the
information gathered and determinations made during the previous steps.
The level of risk is determined by analyzing the values assigned to the
overall likelihood of threat occurrence and the resulting impact of
threat occurrence.
Document the risk assessment results. Once the risk
assessment has been completed as described above, the results of the
risk assessment should be documented. Principally, the regulated entity
should document all threat/vulnerability pairs (i.e., a scenario in
which an identified threat can exploit a vulnerability) applicable to
the organization, the likelihood and impact calculations, and the
overall risk to ePHI for the threat/vulnerability pair. Regulated
entities should consider sharing the risk assessment results with
organizational leadership, whose review can be crucial to the
organization's ongoing risk management.
The Department has also published guidance that explains the
differences between a risk analysis and a gap analysis, and the use of
both in an entity's risk management program.\470\ While a risk analysis
is a comprehensive identification of risks and vulnerabilities to all
ePHI, a gap analysis typically provides a partial assessment of an
entity's enterprise and is often used to provide a high-level overview
of what safeguards are in place (or missing) and may also be used to
review a regulated entity's compliance with particular standards and
implementation specifications of the Security Rule.
---------------------------------------------------------------------------
\470\ ``Risk Analyses vs. Gap Analyses--What is the
difference?'' Cybersecurity Newsletter, Office for Civil Rights,
U.S. Department of Health and Human Services (Apr. 2018), https://www.hhs.gov/sites/default/files/cybersecurity-newsletter-april-2018.pdf.
---------------------------------------------------------------------------
Other NIST guidance on conducting risk assessments explains that
the result of a risk analysis is a determination of risk posed to the
regulated entity's ePHI and related information systems.\471\
[[Page 940]]
Consistent with the discussion above, a key step is determining the
risk level posed to such ePHI by threats and vulnerabilities and how
critical it is to address and mitigate the identified risk. In general,
the descriptive words ``very high'' or ``critical'' are used to
indicate that a threat event could be expected to have multiple severe
or catastrophic adverse effects on organizational operations,
organizational assets, individuals, other organizations, or the
country.\472\ A ``high'' risk would indicate that a threat event could
be expected to have a severe or catastrophic adverse effect on the
same, while a ``moderate'' risk could indicate that the threat event
could have a serious adverse effect on the same. Risks that are ``low''
and ``very low'' could be expected to have a limited and negligible
effect, respectively, on organizational operations or assets,
individuals, other organizations, or the country.
---------------------------------------------------------------------------
\471\ Joint Task Force, ``Guide for Conducting Risk
Assessments,'' NIST Special Publication 800-30, Revision 1, National
Institute of Standards and Technology, U.S. Department of Commerce
(Sept. 2012), https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.
\472\ Id. at Appendix I; see also ``Reducing the Significant
Risk of Known Exploited Vulnerabilities,'' Cybersecurity &
Infrastructure Security Agency, U.S. Department of Homeland Security
(Nov. 3, 2021), https://www.cisa.gov/sites/default/files/publications/Reducing_the_Significant_Risk_of_Known_Exploited_Vulnerabilities_211103.pdf.
---------------------------------------------------------------------------
The Department believes that determinations of risk level and
criticality may vary based on the specific type of regulated entity and
the regulated entity's specific circumstances. For example, a health
care provider must consider the higher levels of risks to physical and
technical security that are created by regular entry and exit of
individuals seeking health care and other members of the public into
its facilities, creating potentially numerous avenues for access to
ePHI through technology assets; in contrast, a health plan that
generally does not permit physical entry by individuals into its office
building may determine that the risks to ePHI from physical entry by
individuals or other members of the public is low because its workforce
members do not generally physically interact with the public. As
another example, a vulnerability permitting unauthenticated remote code
execution on a device connected to a regulated entity's relevant
electronic information systems would likely constitute either a high or
critical risk. However, should such a device not have the ability to
connect to the network, the risk might be low or moderate because the
likelihood of triggering a network vulnerability on a non-networked
device is low, even though the impact of such trigger might be high.
Thus, it is essential that a regulated entity consider its specific
circumstances when assessing the criticality of a risk and to address
such risks in a manner that is appropriate to its specific facts and
circumstances.\473\ In yet another example, a regulated entity in
possession of legacy devices or devices that are nearing the end of
their lifespan should assess the risks associated with continued use of
such devices as part of its risk analysis and ensure that replacement
of such devices and/or the implementation of compensating controls are
included in its risk management plan.
---------------------------------------------------------------------------
\473\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 16-22.
---------------------------------------------------------------------------
Despite our having made available an abundance of free and widely-
publicized guidance tools, OCR unfortunately has learned through its
compliance and enforcement activities that regulated entities often do
not perform compliant risk analyses. As discussed above, in 2016 and
2017, the Department conducted audits of 166 covered entities and 41
business associates for their compliance with selected provisions of
the HIPAA Rules.\474\ These audits confirmed that only small
percentages of covered entities (14 percent) and business associates
(17 percent) were substantially fulfilling their regulatory
responsibilities to safeguard ePHI they hold through risk analysis
activities. Entities generally failed to:
---------------------------------------------------------------------------
\474\ ``2016-2017 HIPAA Audits Industry Report,'' supra note
121.
---------------------------------------------------------------------------
Identify and assess the risks to all of the ePHI in their
possession or even develop and implement policies and procedures for
conducting a risk analysis.
Identify threats and vulnerabilities to consider their
potential likelihoods and effects, and to rate the risk to ePHI.
Review and periodically update a risk analysis in response
to changes in the environment and/or operations, security incidents, or
occurrence of a significant event.
Conduct risk analyses consistent with policies and
procedures.
Failing to document any efforts to develop, maintain, and update
policies and procedures for conducting risk analyses was common. For
example, health care providers commonly submitted documentation of some
security activities performed by a third-party security vendor, without
submitting documentation of any risk analysis that served as the basis
of such activities.\475\ Many regulated entities used and relied on
outside persons to manage or perform risk analyses for their
organizations; however, these outside persons frequently failed to meet
the requirements of the Security Rule. Regulated entities also
frequently and incorrectly assumed that a purchased security product
satisfied all of the Security Rule's requirements.
---------------------------------------------------------------------------
\475\ Id.
---------------------------------------------------------------------------
The responsibility to maintain an appropriate risk analysis rests
with the regulated entity. Accordingly, it is essential that regulated
entities understand and comply with risk analysis requirements to
appropriately safeguard PHI.
Numerous OCR investigations reflect the failure of regulated
entities to develop and implement holistic risk analysis programs. For
example, OCR's investigation of a health system in the aftermath of a
ransomware attack found evidence of potential failures to: conduct a
compliant risk analysis to determine the potential risks and
vulnerabilities to ePHI in its systems; implement a contingency plan to
respond to emergencies, like a ransomware attack, that damage systems
that contain ePHI; and implement policies and procedures to allow only
authorized users access to ePHI.\476\
---------------------------------------------------------------------------
\476\ Press Release, ``HHS Office for Civil Rights Settles HIPAA
Security Rule Failures for $950,000,'' U.S. Department of Health and
Human Services (July 1, 2024), https://prod-wwwhhsgov.cloud.hhs.gov/about/news/2024/07/01/hhs-office-civil-rights-settles-hipaa-security-rule-failures-950000.html.
---------------------------------------------------------------------------
In another recently concluded investigation involving a large
medical center, the covered entity reported that over a seven-month
period, one of its employees inappropriately accessed the ePHI of more
than 12,000 patients and then sold certain patient information to an
identity theft ring.\477\ OCR's investigation indicated potential
violations of the requirement to conduct an accurate and thorough risk
analysis of the potential risks and vulnerabilities to the
confidentiality, integrity, and availability of all of the ePHI held by
the medical center, as well as the requirement at 45 CFR
164.308(a)(1)(ii)(D) to implement procedures to regularly review
records of information system activity, such as audit logs, access
reports, and security incident tracking.
---------------------------------------------------------------------------
\477\ See ``Montefiore Medical Center,'' supra note 248.
---------------------------------------------------------------------------
In another case, the OCR settled a ransomware cyberattack
investigation with a business associate.\478\ The cyberattack affected
the ePHI of over
[[Page 941]]
200,000 individuals when the business associate's network server was
infected with ransomware. It took the company more than 18 months to
detect the intrusion, and they only did so when the ransomware was used
by the intruder to encrypt the company's files. Among other factors,
OCR's investigation found evidence of potential failures to conduct an
accurate and thorough risk analysis and to implement procedures to
regularly review records of information system activity, such as audit
logs, access reports, and security incident tracking reports.
---------------------------------------------------------------------------
\478\ See ``Doctors' Management Services, Inc.,'' supra note
246.
---------------------------------------------------------------------------
Given the compliance deficiencies that OCR regularly sees--those
cited as examples and what OCR has observed more broadly--we believe
that stronger requirements coupled with greater specificity regarding
the components of a risk analysis would help and encourage regulated
entities to appropriately perform such activities. Accordingly, the
Department proposes to elevate the requirement to conduct a risk
analysis from an implementation specification at 45 CFR
164.308(a)(1)(ii)(A) to a standard at proposed 45 CFR 164.308(a)(2)(i).
Under the proposal, and consistent with NCVHS' recommendations,\479\ a
regulated entity would be required to conduct an accurate and
comprehensive written assessment of the potential risks and
vulnerabilities to the confidentiality, integrity, and availability of
all ePHI created, received, maintained, or transmitted by the regulated
entity.
---------------------------------------------------------------------------
\479\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 4-6.
---------------------------------------------------------------------------
The Department proposes eight implementation specifications for the
risk analysis standard, consistent with previously issued guidance
described above. The proposed implementation specification for a
written assessment at proposed paragraph (a)(2)(ii)(A) would require
the regulated entity, at a minimum, to perform and document all of the
following: \480\
---------------------------------------------------------------------------
\480\ Proposed 45 CFR 164.308(a)(2)(ii)(A).
---------------------------------------------------------------------------
Review the technology asset inventory and the network map
to identify where ePHI may be created, received, maintained, or
transmitted within its information systems.\481\
---------------------------------------------------------------------------
\481\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(1).
---------------------------------------------------------------------------
Identify all reasonably anticipated threats to the
confidentiality, integrity, and availability of ePHI that it creates,
receives, maintains, or transmits.\482\
---------------------------------------------------------------------------
\482\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(2).
---------------------------------------------------------------------------
Identify potential vulnerabilities and predisposing
conditions to the regulated entity's relevant electronic information
systems--that is, its electronic information systems that create,
receive, maintain, or transmit ePHI or that otherwise affect the
confidentiality, integrity, or availability of ePHI.\483\
---------------------------------------------------------------------------
\483\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(3).
---------------------------------------------------------------------------
Create an assessment and documentation of the security
measures it uses to ensure that the measures protect the
confidentiality, integrity, and availability of the ePHI created,
received, maintained, or transmitted by the regulated entity.\484\
---------------------------------------------------------------------------
\484\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(4).
---------------------------------------------------------------------------
Make a reasonable determination of the likelihood that
each identified threat would exploit the identified
vulnerabilities.\485\ For example, a regulated entity located on the
west coast could consult actuarial tables to reasonably determine the
likelihood that an earthquake would affect access to electrical power
to maintain its relevant electronic information systems.
---------------------------------------------------------------------------
\485\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(5).
---------------------------------------------------------------------------
Make a reasonable determination of the potential impact of
each identified threat should it successfully exploit the identified
vulnerabilities.\486\ For example, the regulated entity described above
could make a reasonable determination of how and the extent to which
the lack of electrical power caused by an earthquake would affect the
availability and integrity of ePHI in its relevant electronic
information system.
---------------------------------------------------------------------------
\486\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(6).
---------------------------------------------------------------------------
Create an assessment of risk level for each identified
threat and vulnerability.\487\
---------------------------------------------------------------------------
\487\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(7).
---------------------------------------------------------------------------
Create an assessment of risks to ePHI posed by entering
into or continuing a business associate agreement or other written
arrangement with any prospective or current business associate,
respectively, based on the written verification obtained from the
prospective or current business associate.\488\
---------------------------------------------------------------------------
\488\ Proposed 45 CFR 164.308(a)(2)(ii)(A)(8).
---------------------------------------------------------------------------
Under the proposed implementation specification for maintenance at
proposed 45 CFR 164.308(a)(2)(ii)(B), a regulated entity additionally
would be required to review, verify, and update the written assessment
on an ongoing basis, but in any event no less frequently than at least
once every 12 months, and in response to a change in the regulated
entity's environment or operations that may affect ePHI. As discussed
above, a change in the regulated entity's environment or operations
that may affect ePHI would include, but would not be limited to, the
adoption of new technology assets; the upgrading, updating, or patching
of technology assets; newly recognized threats to the confidentiality,
integrity, or availability of ePHI; a sale, transfer, merger, or
consolidation of all or part of the regulated entity with another
person; a security incident that affects the confidentiality,
integrity, or availability of ePHI; and relevant changes in Federal,
State, Tribal, or territorial law.
e. Section 164.308(a)(3)(i)--Standard: Evaluation
The Department proposes to redesignate the existing evaluation
standard at 45 CFR 164.308(a)(8) as 45 CFR 164.308(a)(3)(i) and to
revise the redesignated evaluation standard to require the technical
and nontechnical evaluation(s) to be in writing and performed to
determine whether change in the regulated entity's environment or
operations may affect the confidentiality, integrity, or availability
of ePHI. Evaluating the effects of a potential change on a regulated
entity's environment or operations, including the effects on the
confidentiality, integrity, and availability of ePHI, is a critical
step in the change control process. An evaluation serves a similar
purpose to a risk analysis. However, while a risk analysis looks at the
entirety of a regulated entity's enterprise regularly and in response
to a change in the regulated entity's environment or operations, an
evaluation looks at a specific change that a regulated entity intends
to make before the change is made. Thus, this proposal, if adopted,
would ensure that a regulated entity proactively considers whether any
risks or vulnerabilities to ePHI or its relevant electronic information
systems will be introduced by changes it intends to make to its
environment or operations and responds by implementing appropriate
safeguards in a timely fashion.\489\
---------------------------------------------------------------------------
\489\ See NCVHS recommendation to test at multiple points in the
life cycle of a system, including ``at every significant change
throughout the life of the system[.]'' Letter from NCVHS Chair Jacki
Monson (2023), supra note 123, Appendix p. 6.
---------------------------------------------------------------------------
We also propose to delete the requirement that the evaluation be
performed ``based initially on the standards implemented under this
rule'' because an evaluation is performed to assess the effect(s) of a
planned change on the environment, which can be observed when those
effects are compared to the environment reflected in the risk analysis.
Additionally, the Department proposes to add two implementation
specifications at
[[Page 942]]
proposed 45 CFR 164.308(a)(3)(ii). The proposed implementation
specification for performance at proposed 45 CFR 164.308(a)(3)(ii)(A)
would require that a regulated entity conduct the evaluation within a
reasonable period of time before making a change to its environment or
operations, while the proposed implementation specification for
response at proposed 45 CFR 164.308(a)(3)(ii)(B) would require a
regulated entity to respond to the evaluation in accordance with its
risk management plan.
A change in the regulated entity's environment or operations would
include, but would not be limited to, the adoption of new technology
assets; the upgrading, updating, or patching of technology assets;
newly recognized threats to the confidentiality, integrity, or
availability of ePHI; a sale, transfer, merger or consolidation of all
or part of the regulated entity with another person; a security
incident that affects the confidentiality, integrity, or availability
of ePHI; and relevant changes in Federal, State, Tribal, and
territorial law.
NIST guidance provides descriptions of key activities and sample
questions that would help regulated entities meet this evaluation
standard.\490\ They include:
---------------------------------------------------------------------------
\490\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461; ``Security Rule Guidance Material,'' Office
for Civil Rights, U.S. Department of Health and Human Services (Feb.
16, 2024), https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html?language=es.
---------------------------------------------------------------------------
Determine whether internal or external evaluation is most
appropriate. Which staff has the technical experience and expertise to
evaluate the systems? If an outside vendor is used, what factors should
be considered when selecting the vendor, such as credentials and
experience?
Develop standards and measurements for reviewing all
standards and implementation specifications of the Security Rule. Have
management, operational, and technical issues been considered? Do the
elements of each evaluation procedure (e.g., questions, statements, or
other components) address individual, measurable security safeguards
for ePHI?
Conduct an evaluation. Has the process been formally
communicated to those who have been assigned roles and responsibilities
in the evaluation process? Has the organization explored the use of
automated tools to support the process?
Document results, including: each evaluation finding and
remediation options, recommendations, and decisions; known gaps between
identified risks, mitigating security controls, and any acceptance of
risk, including justification; developed security program priorities
and established targets for continuous improvement; use of evaluation
results to inform security changes to protect ePHI; communication of
evaluation results, metrics, and/or measurements to relevant
organizational personnel.
Repeat evaluations periodically. Establish the frequency
of evaluations, repeating evaluations when environmental and
operational changes that affect the security of ePHI are made (e.g., if
new technology is adopted or if there are newly recognized risks to the
confidentiality, integrity, or availability of ePHI).
Despite the existing standard and the availability of guidance,
many regulated entities do not evaluate how changes in their
environment, such as a merger or acquisition or implementation of new
technology, may affect the security of ePHI. In some instances,
regulated entities assert that they have done so, but have no
documentation of the purported evaluation. The Department believes that
this proposal, if adopted, would clarify our expectations for
implementing these safeguards.
f. Section 164.308(a)(4)(i)--Standard: Patch Management
As described in Department guidance, regulated entities can defend
themselves from common cyberattacks, but hackers continue to target the
health care industry in search of ways to access valuable ePHI.\491\
Accordingly, timely implementation of patches for known vulnerabilities
is crucial to maintaining the security of ePHI. Many cyberattacks could
be prevented or substantially mitigated if regulated entities
implemented activities to manage the implementation of patches,
updates, and upgrades to comply with the Security Rule's requirements
for risk management, which can deter one of the common types of
attacks: exploitation of known vulnerabilities. If an attack is
successful, the intruder often will encrypt a regulated entity's ePHI
to hold it for ransom, or exfiltrate the data for future purposes
including identity theft or blackmail. Cyberattacks are especially
concerning in the health care sector because they can disrupt the
provision of health care services. Exploitable vulnerabilities can
exist in many parts of a regulated entity's information systems, but
often, known vulnerabilities can be mitigated by applying vendor
patches, updating software or system configurations, or upgrading to a
newer version of the product. If a patch, update, or upgrade is
unavailable, vendors often suggest actions to take, that is,
compensating controls, to mitigate a newly discovered vulnerability.
Such actions could include modifications of configuration files or
disabling of affected services. Regulated entities should pay careful
attention to cybersecurity alerts describing newly discovered
vulnerabilities. These alerts often include information on mitigation
activities and patching.
---------------------------------------------------------------------------
\491\ See ``Defending Against Common Cyber-Attacks,'' supra note
396.
---------------------------------------------------------------------------
Risk management processes that are compliant with the Security Rule
include identifying and mitigating risks and vulnerabilities that
unpatched software poses to an organization's ePHI. Mitigation
activities could include installing patches if patches are available
and patching is reasonable and appropriate. In situations where patches
are not available (e.g., obsolete or unsupported software) or testing
or other concerns weigh against patching as a mitigation solution,\492\
regulated entities should implement reasonable compensating controls to
reduce the risk of identified vulnerabilities to a reasonable and
appropriate level (e.g., restricting network access or disabling
network services to reduce vulnerabilities that could be exploited via
network access). Security vulnerabilities may be present in many types
of software, including databases, EHRs, operating systems, email, and
device firmware. Each type of program would have its own unique set of
vulnerabilities and challenges for applying patches, but identifying
and mitigating the risks unpatched software
[[Page 943]]
poses to ePHI is important to ensuring that ePHI is protected.\493\
---------------------------------------------------------------------------
\492\ It may not be reasonable and appropriate for a regulated
entity to patch software or update a system configuration where the
risk of introducing a change is greater than the status quo risk or
where the regulated entity does not own or manage a networked
device. For example, instances where it might not be reasonable and
appropriate to patch or update an information system include: (1)
where a system needs to run continuously for mission critical
support and is not patched or updated during its lifetime; and (2)
where the regulated entity's testing of such patch or update
indicates potential adverse impacts or where industry is reporting
adverse impacts of such patch or update. This does not negate the
regulated entity's need to address the vulnerability with a
compensating control. For example, where a hospital discovers a
vulnerability on a device that is connected to its network but owned
and managed by a business associate, the hospital may not have
access to install a patch, but it should employ a compensating
control, such as disabling or limiting that device's access to the
hospital's network.
\493\ See ``Guidance on Software Vulnerabilities and Patching,''
Cybersecurity Newsletter, Office for Civil Rights, U.S. Department
of Health and Human Services (June 2018), https://www.hhs.gov/sites/default/files/june-2018-newsletter-software-patches.pdf.
---------------------------------------------------------------------------
Although older applications or devices may no longer be supported
with patches for new vulnerabilities, regulated entities must still
take appropriate action if a newly discovered vulnerability affects an
older application or device. If an obsolete, unsupported system cannot
be upgraded or replaced, additional safeguards should be implemented or
existing safeguards enhanced to mitigate known vulnerabilities until
upgrade or replacement can occur (e.g., increase access restrictions,
remove or restrict network access, disable unnecessary features or
services).\494\
---------------------------------------------------------------------------
\494\ See ``Securing Your Legacy [System Security],''
Cybersecurity Newsletter, Office for Civil Rights, U.S. Department
of Health and Human Services (Oct. 2021), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-fall-2021/index.html.
---------------------------------------------------------------------------
Patches can be applied to software and firmware on all types of
devices--telephones, computers, servers, routers, and more.
Installation of vendor-recommended patches is typically a routine
process. However, regulated entities should be prepared if issues arise
as a result of applying patches. Software and hardware are often
interconnected and dependent on the functionality and output of other
information systems or components of other information systems. When
certain changes are made, including the installation of a patch,
software dependent on the changed application may not perform as
expected because settings or data may be affected. Thus, in complex
environments, patch management plays a crucial role in the safe and
correct implementation of these changes.\495\ Enterprise patch
management is the process of identifying, prioritizing, acquiring,
installing, and verifying the installation of patches, updates, and
upgrades throughout an organization.\496\ NIST has issued a series of
guidance documents that regulated entities can use to design their own
patch management processes as part of their risk management plans.
---------------------------------------------------------------------------
\495\ See ``Guidance on Software Vulnerabilities and Patching,''
supra note 493.
\496\ See Murugiah Souppaya, et al., ``Guide to Enterprise Patch
Management Planning: Preventive Maintenance for Technology,'' NIST
Special Publication 800-40, Revision 4, National Institute of
Standards and Technology, U.S. Department of Commerce (Apr. 2022),
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf.
---------------------------------------------------------------------------
Consistent with previously issued guidance, the discussion above,
and recommendations from NCVHS,\497\ the Department proposes a new
standard for patch management at proposed 45 CFR 164.308(a)(4)(i) that
would require a regulated entity to implement written policies and
procedures for applying patches and updating the configurations of its
relevant electronic information systems. This proposed standard would
ensure that a regulated entity is aware of its liability for
appropriately safeguarding ePHI by installing patches, updates, and
upgrades throughout its relevant electronic information systems.
---------------------------------------------------------------------------
\497\ Letter from NCVHS Chair Jacki Monson (2023), supra note
123, Appendix p. 1; Letter from NCVHS Chair Jacki Monson (2022),
supra note 123, p. 8-9.
---------------------------------------------------------------------------
The Department proposes six implementation specifications at
proposed 45 CFR 164.308(a)(4)(ii) that would be associated with the
proposed standard for patch management. The proposed implementation
specification for policies and procedures at proposed paragraph
(a)(4)(ii)(A) would require a regulated entity to establish written
policies and procedures for identifying, prioritizing, acquiring,
installing, evaluating, and verifying the timely installation of
patches, updates, and upgrades throughout its electronic information
systems that create, receive, maintain, or transmit ePHI or that
otherwise affect the confidentiality, integrity, or availability of
ePHI. Under the proposed implementation specification for maintenance
at proposed paragraph (a)(4)(ii)(B), a regulated entity would be
required to review its patch management written policies and procedures
at least once every 12 months and modify them as reasonable and
appropriate based on that review. The proposed implementation
specification for application at proposed paragraph (a)(4)(ii)(C) would
require a regulated entity to patch, update, and upgrade the
configurations of its relevant electronic information systems in
accordance with its written policies and procedures and based on the
results of: the regulated entity's risk analysis that would be required
by proposed 45 CFR 164.308(a)(2), the vulnerability scans that would be
required under proposed 45 CFR 164.312(h)(2)(i), the monitoring of
authoritative sources that would be required under proposed 45 CFR
164.312(h)(2)(ii), and penetration tests proposed at 45 CFR
164.312(h)(2)(iii). The proposal would require that such actions be
taken within a reasonable and appropriate period of time, except to the
extent that an exception in proposed paragraph (h)(2)(ii)(D) applies.
Specifically, a reasonable and appropriate period of time to patch,
update, or upgrade the configuration of a relevant electronic
information system would be within 15 calendar days of identifying the
need to address a critical risk where a patch, update, or upgrade is
available; or, where a patch, update, or upgrade is not available,
within 15 calendar days of a patch, update, or upgrade becoming
available. The proposal would require that, within 30 calendar days of
identifying the need to address a high risk,\498\ a regulated entity
patch, update, or upgrade the configuration of a relevant electronic
information system where a patch, update, or upgrade is available; or,
where a patch, update, or upgrade is not available, within 30 calendar
days of a patch, update, or upgrade becoming available. For all other
patches, updates, or upgrades to the configurations of relevant
electronic information systems, a reasonable and appropriate period of
time would be determined by the regulated entity's written policies and
procedures for identifying, prioritizing, acquiring, installing,
evaluating, and verifying the timely installation of patches, updates,
and upgrades.
---------------------------------------------------------------------------
\498\ An explanation of risk rating is provided above in the
discussion of the proposed standard for risk analysis and associated
implementation specifications.
---------------------------------------------------------------------------
For the proposed exceptions to apply, we propose in proposed
paragraph (a)(4)(ii)(D) that a regulated entity would be required to
document that an exception applies and that all other applicable
conditions are met. The first proposed exception in proposed 45 CFR
164.308(a)(4)(ii)(D)(1) would be for when a patch, update, or upgrade
to the configuration of a relevant electronic information system is not
available to address a risk identified in the regulated entity's risk
analysis. The second proposed exception would be in proposed 45 CFR
164.308(a)(4)(ii)(D)(2) for when the only available patch, update, or
upgrade would adversely affect the confidentiality, integrity, or
availability of ePHI. The Department anticipates that this proposed
exception would apply when a regulated entity tests a patch, update, or
upgrade and determines that it would adversely affect the
confidentiality, integrity, or availability of ePHI or where there are
reports from government sources or persons with appropriate knowledge
of an experience with generally accepted cybersecurity principles and
methods for ensuring the confidentiality, integrity, and availability
of ePHI indicating that the patch, update, or
[[Page 944]]
upgrade is likely to adversely affect the confidentiality, integrity,
or availability of ePHI.
In proposed paragraph (a)(4)(ii)(E), the Department proposes to
require a regulated entity document in real-time the existence of the
applicable exception and to implement reasonable and appropriate
compensating controls. Similarly, in proposed paragraph (a)(4)(ii)(F),
we propose that, where an exception applies, a regulated entity would
be required to implement reasonable and appropriate security measures
as compensating controls to address the identified risk according to
the timeliness requirements in proposed 45 CFR 164.308(a)(5)(ii)(D)
until such time as a patch, update, or upgrade that does not adversely
affect the confidentiality, integrity, or availability of ePHI becomes
available.
This proposed standard aligns with the Department's enhanced CPG
for Cybersecurity Mitigation by quickly requiring a regulated entity to
prioritize and mitigate vulnerabilities discovered by vulnerability
scanning and penetration testing.\499\
---------------------------------------------------------------------------
\499\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
g. Section 164.308(a)(5)(i)--Standard: Risk Management
The Department proposes to elevate the implementation specification
for risk management to a standard at proposed 45 CFR 164.308(a)(5)(i).
This proposed standard would require a regulated entity to establish
and implement a plan for reducing the risks identified through its risk
analysis activities. Specifically, it would require a regulated entity
to implement security measures sufficient to reduce risks and
vulnerabilities to all ePHI to a reasonable and appropriate level. What
would constitute a reasonable and appropriate level depends on the
regulated entity's specific circumstances, including but not limited to
its size, needs and capabilities, risk profile, the ability of security
measures to reduce or eliminate a particular identified risk or
vulnerability, and the ubiquity of such security measures. We also
propose four implementation specifications that would require regulated
entities to engage in activities that are consistent with previously
issued guidance described below.
Under the proposed implementation specification for planning at
proposed paragraph (a)(5)(ii)(A), a regulated entity would be required
to establish and implement a written risk management plan for reducing
risks to all ePHI, including, but not limited to, those risks
identified by the regulated entity's risk analysis,\500\ to a
reasonable and appropriate level. Proposed paragraph (a)(5)(i)(B)
contains the proposed implementation specification for maintenance and
would require the regulated entity to review the written risk
management plan at least once every 12 months, and as reasonable and
appropriate in response to changes in its risk analysis. The Department
would interpret ``reasonable and appropriate'' in both paragraphs as
requiring the regulated entity to take into account not only its
specific circumstances, but also the criticality of the risks
identified. We propose an implementation specification for priorities
at proposed 45 CFR 164.308(a)(5)(ii)(C) that would require a regulated
entity's written risk management plan to prioritize the risks
identified in the regulated entity's risk analysis based on the risk
levels determined by that analysis. Finally, in the proposed
implementation specification for implementation at proposed 45 CFR
164.308(a)(5)(ii)(D), we propose to require that a regulated entity
implement security measures in a timely manner to address the risks
identified in the regulated entity's risk analysis in accordance with
the priorities established under paragraph (a)(5)(ii)(C). The proposed
risk management standard aligns with the Department's essential CPG to
Mitigate Known Vulnerabilities.\501\
---------------------------------------------------------------------------
\500\ See proposed 45 CFR 164.308(a)(2).
\501\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
The Department previously issued guidance on risk management,
including links to NIST resources, that is consistent with what we
propose in this NPRM.\502\ We encourage regulated entities to refer to
similar NIST guidance for descriptions of risk management
activities.\503\ The results of a risk analysis, performed in
accordance with the proposed standard for risk analysis, generally
provide the regulated entity with a list of applicable ``threat/
vulnerability pairs'' as well as the overall ``risk rating'' of each
pair to the confidentiality, integrity, and availability of ePHI.\504\
For example, some threat/vulnerability pairs may result in a risk
rating of moderate or high level of risk to ePHI, while other pairs may
result in a risk rating of low level of risk. The regulated entity
would need to determine what risk rating poses an unacceptable level of
risk to ePHI and address any threat/vulnerability pairs that indicate a
risk rating above the organization's risk tolerance.\505\
---------------------------------------------------------------------------
\502\ See ``6 Basics of Risk Analysis and Risk Management,''
HIPAA Security Series, Volume 2, Paper 6, Centers for Medicare &
Medicaid Services (June 2005, revised Mar. 2007), https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/riskassessment.pdf?language=es.
\503\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\504\ See id. at 18.
\505\ See id. at 25.
---------------------------------------------------------------------------
Under this proposed standard, the regulated entity would be
required to reduce the risks to its ePHI to a level that is reasonable
and appropriate for its specific circumstances. Ultimately, the
regulated entity's risk assessment processes should inform its
decisions about the manner in which it will implement security measures
to comply with the Security Rule's standards and implementation
specifications.\506\ Additionally, each regulated entity would be
required to document the security controls it has implemented because
it has determined them to be reasonable and appropriate, including
analyses, decisions, and the rationale for decisions made to refine or
adjust the security controls.\507\
---------------------------------------------------------------------------
\506\ Id.
\507\ See proposed 45 CFR 164.306(d) and 164.316(b)(1).
---------------------------------------------------------------------------
As stated by NIST, ``the documentation and retention of risk
assessment and risk management activities'' is ``important for future
risk management efforts.'' \508\ In general, risk management activities
``should be performed with regular frequency to examine past decisions,
reevaluate risk likelihood and impact levels, and assess the
effectiveness of past remediation efforts.'' \509\ Risk management
plans should address risk appetite, risk tolerance, workforce duties,
responsible parties, the frequency of risk management, and required
documentation.\510\
---------------------------------------------------------------------------
\508\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 27.
\509\ See id. at 31.
\510\ See id.
---------------------------------------------------------------------------
h. Section 164.308(a)(6)(i)--Standard: Sanction Policy
Consistent with other proposals to elevate certain critical
implementation specifications to standards, we propose to elevate the
implementation specification for sanction policy at 45 CFR
164.308(a)(ii)(C) to a standard for sanction policy at proposed 45 CFR
164.308(a)(6)(i). We propose this standard because applying appropriate
sanctions against workforce members who fail to comply with security
requirements, and thus imperil the
[[Page 945]]
security of ePHI, serves as an important tool for improving compliance
by other workforce members with the regulated entity's safeguards for
ePHI. While the Department does not propose to modify the language of
the standard, we are proposing three implementation specifications that
are consistent with guidance that was previously issued by the
Department.
Specifically, under the proposed implementation specification for
policies and procedures at proposed 45 CFR 164.308(a)(6)(ii)(A), a
regulated entity would be required to establish written policies and
procedures for sanctioning workforce members who fail to comply with
the regulated entity's security policies and procedures. The proposed
implementation specification for modifications at paragraph
(a)(6)(ii)(B) would require a regulated entity to review its written
sanctions policies and procedures at least once every 12 months, and,
based on that review, modify such policies and procedures as reasonable
and appropriate. The proposed implementation specification for
application at proposed paragraph (a)(6)(ii)(C) would direct a
regulated entity to apply appropriate sanctions against workforce
members who fail to comply with such security policies and procedures
and to document when it sanctions a workforce member and the
circumstances in which it applies such sanctions.
The policy choices represented in this NPRM are informed by the
compliance challenges OCR has observed through its enforcement
activities. These challenges demonstrate that regulated entities would
benefit from greater precision and clarity about their legal
obligations in the proposed standard. Additionally, according to a
recent survey of IT and IT security practitioners in healthcare,
careless users were the top cause of data loss and exfiltration, while
accidental loss was the second highest cause. Thirty-one percent of
respondents indicated that the data loss or exfiltration was caused by
a failure of workforce members to follow organizational policies.\511\
As described in existing Department guidance, an organization's
sanction policies can be an important tool for supporting
accountability and improving cybersecurity and data protection.\512\
Sanction policies can be used to address the intentional actions of
malicious insiders, such as a workforce member that accesses the ePHI
of a public figure or steals ePHI to sell as part of an identity-theft
ring, as well as the failure of workforce members to comply with
policies and procedures, such as failing to secure data on a network
server or investigate a potential security incident.
---------------------------------------------------------------------------
\511\ ``The 2024 Study on Cyber Insecurity in Health Care: The
Cost and Impact on Patient Safety and Care,'' supra note 143, p. 7.
\512\ See ``How Sanction Policies Can Support HIPAA
Compliance,'' Cybersecurity Newsletter, Office for Civil Rights,
U.S. Department of Health and Human Services (Oct. 2023), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-october-2023/index.html#ftn10.
---------------------------------------------------------------------------
Sanction policies that are appropriately applied can improve a
regulated entity's general compliance with the HIPAA Rules. Imposing
consequences on workforce members who violate a regulated entity's
policies and procedures implemented as required by the Security Rule or
the HIPAA Rules generally can be effective in creating a culture of
HIPAA compliance and improved cybersecurity. Knowledge that there is a
negative consequence to noncompliance enhances the likelihood of
compliance.\513\ Training workforce members on a regulated entity's
sanction policy can also promote compliance and greater cybersecurity
vigilance by informing workforce members in advance which actions are
prohibited and punishable.\514\ A sanction policy that clearly
communicates a regulated entity's expectations should ensure that
workforce members understand their individual compliance obligations
and consequences of noncompliance.
---------------------------------------------------------------------------
\513\ 68 FR 8334, 8347 (Feb. 20, 2003).
\514\ 65 FR 82462, 82747 (Dec. 28, 2000).
---------------------------------------------------------------------------
Regulated entities have the flexibility to implement the standard
in a manner consistent with numerous factors, including but not limited
to their size, degree of risk, and environment. The HIPAA Rules do not
require regulated entities to impose any specific penalty for any
particular violation, nor do they require regulated entities to
implement any particular methodology for sanctioning workforce members.
Rather, in any particular case, each regulated entity must determine
the type, cause, and severity of sanctions imposed based upon its
policies and the relative severity of the violation.\515\ A regulated
entity may structure its sanction policies in the manner most suitable
to its organization. As described in previously issued guidance
materials from the Department and NIST, regulated entities should
consider the following when drafting or revising their sanction
policies:
---------------------------------------------------------------------------
\515\ 68 FR 8334, 8347 (Feb. 20, 2003).
---------------------------------------------------------------------------
Documenting or implementing sanction policies pursuant to
a formal process.\516\
---------------------------------------------------------------------------
\516\ 65 FR 82462, 82562 (Dec. 28, 2000).
---------------------------------------------------------------------------
Requiring workforce members to affirmatively acknowledge
that a violation of the organization's HIPAA policies or procedures may
result in sanctions.\517\
---------------------------------------------------------------------------
\517\ See ``Security Standards: Administrative Safeguards,''
HIPAA Security Series, Volume 2, Paper 2, Centers for Medicare &
Medicaid Services (May 2005, revised Mar. 2007), https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/adminsafeguards.pdf; see also ``Implementing the Health
Insurance Portability and Accountability Act (HIPAA) Security Rule:
A Cybersecurity Resource Guide,'' supra note 461, p. 33.
---------------------------------------------------------------------------
Documenting the sanction process, including the personnel
involved, the procedural steps, the time-period, the reason for the
sanction(s), and the final outcome of an investigation.\518\
---------------------------------------------------------------------------
\518\ Records of sanction activity should be retained for at
least six years. See 45 CFR 164.316 and 164.530(e)(2).
---------------------------------------------------------------------------
Creating sanctions that are ``appropriate to the nature of
the violation.'' \519\
---------------------------------------------------------------------------
\519\ See 65 FR 82462, 82562 (Dec. 28, 2000).
---------------------------------------------------------------------------
Creating sanctions that ``vary depending on factors such
as the severity of the violation, whether the violation was intentional
or unintentional, and whether the violation indicated a pattern or
practice of improper use or disclosure of [PHI].'' \520\
---------------------------------------------------------------------------
\520\ Id.
---------------------------------------------------------------------------
Creating sanctions that ``range from a warning to
termination.'' \521\
---------------------------------------------------------------------------
\521\ Id.
---------------------------------------------------------------------------
Providing examples ``of potential violations of policy and
procedures.'' \522\
---------------------------------------------------------------------------
\522\ See ``Security Standards: Administrative Safeguards,''
supra note 517.
---------------------------------------------------------------------------
Generally, it is important for a regulated entity to consider
whether its sanction policies align with its general disciplinary
policies, and how the individuals or departments involved in the
sanction processes can work in concert, when appropriate. Regulated
entities may also want to consider how sanction policies can be fairly
and consistently applied throughout the organization, to all workforce
members, including management.\523\ The deterrent effect of penalizing
noncompliance and misconduct paired with clear communications about the
consequences of noncompliance can promote greater compliance with the
HIPAA Rules through accountability, understanding, and transparency.
---------------------------------------------------------------------------
\523\ See 45 CFR 164.308(a)(1)(ii)(C), 164.530(e)(1); see also
65 FR 82462, 82747 (Dec. 28, 2000) (``All members of a covered
entity's workforce are subject to sanctions for violations.'').
---------------------------------------------------------------------------
[[Page 946]]
i. Section 164.308(a)(7)(i)--Standard: Information System Activity
Review
As described in previously issued HHS guidance, review of activity
in its relevant electronic information systems and their components,
including workstations,\524\ enables a regulated entity to determine if
any ePHI has been used or disclosed in an inappropriate manner.\525\
The procedures should be customized to meet the regulated entity's risk
management strategy and consider the capabilities of all information
systems with ePHI.\526\ These activities should also promote continual
awareness of any information system activity that could suggest a
security incident.\527\
---------------------------------------------------------------------------
\524\ Workstations may also be referred to as ``endpoints.'' See
``Memorandum on Improving Detection of Cybersecurity Vulnerabilities
and Incidents on Federal Government Systems through Endpoint
Detection and Response,'' Office of Management and Budget, Executive
Office of the President, p. 1 (Oct. 8, 2021) https://www.whitehouse.gov/wp-content/uploads/2021/10/M-22-01.pdf.
\525\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 5-6.
\526\ See id. at 6.
\527\ Id.
---------------------------------------------------------------------------
Detecting and preventing data leakage initiated by malicious
authorized users is a significant challenge.\528\ Identifying potential
malicious activity in relevant electronic information systems,
including in workstations and other components, as soon as possible is
key to preventing or mitigating the impact of such activity.\529\ To
identify potential suspicious activity, organizations should consider
an insider's interactions with information systems and their
components. A regulated entity can detect anomalous user behavior or
indicators of misuse by either a trusted employee or third-party vendor
who has access to critical systems, workstations and other system
components, and data.\530\ To minimize this risk, an organization may
employ safeguards that detect suspicious user activities, such as
traffic to an unauthorized website, downloading data to an external
device (e.g., thumb drive), or access to a network server by an
unauthorized mobile device. Maintaining audit controls (e.g., system
event logs, application audit logs) and regularly reviewing audit logs,
access reports, and security incident tracking reports are important
security measures that can assist in detecting and identifying
suspicious activity or unusual patterns of data access.\531\
---------------------------------------------------------------------------
\528\ See ``Managing Malicious Insider Threats,'' Cybersecurity
Newsletter, Office for Civil Rights, U.S. Department of Health and
Human Services (Aug. 2019), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-summer-2019/index.html.
\529\ Id.
\530\ Id.
\531\ Id.
---------------------------------------------------------------------------
Regulated entities should regularly review activity in their
relevant electronic information systems (including the components of
such systems) for potential concerns and consider ways to automate such
reviews.\532\ Additionally, regulated entities are responsible for
establishing and implementing appropriate standard operating
procedures, including determining the types of audit trail data and
monitoring procedures that would be needed to derive exception
reports.\533\ They also must activate the necessary review processes
and maintain auditing and logging activity.\534\
---------------------------------------------------------------------------
\532\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 33.
\533\ See id. at 34.
\534\ See id.
---------------------------------------------------------------------------
Department and NIST guidance advise regulated entities to consider
many questions when establishing their policies and procedures for
reviewing activity in their relevant electronic information systems
review.\535\ These include:
---------------------------------------------------------------------------
\535\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 7; see also ``Implementing the Health Insurance
Portability and Accountability Act (HIPAA) Security Rule: A
Cybersecurity Resource Guide,'' supra note 461, p. 30-34.
---------------------------------------------------------------------------
What logs or reports are generated by the information
systems?
Is there a policy that establishes what reviews will be
conducted?
Are there corresponding procedures that describe the
specifics of the reviews?
Who is responsible for the overall process and results?
How often will review results be analyzed?
Where will audit information reside (e.g., separate
server)? Will it be stored external to the organization (e.g., cloud
service provider)?
Compliance challenges observed through OCR's enforcement activities
suggest that regulated entities would benefit from an expanded standard
to provide more details on compliance expectations. Investigations of
reported breaches of unsecured PHI discussed above as examples of risk
analysis failures also identified a potential failure by the regulated
entities to conduct appropriate information system activity
review.\536\ In an investigation involving a large health care
provider, the ePHI of more than 12,000 patients was sold to an identity
theft ring by employees who, for six months, inappropriately accessed
patient account information.\537\ Compliance with the requirement to
implement procedures to regularly review records of activity in
relevant electronic information systems, such as audit logs, access
reports, and security incident tracking, could have identified and
mitigated these disclosures.\538\
---------------------------------------------------------------------------
\536\ See Press Release, ``HHS Office for Civil Rights Settles
HIPAA Security Rule Failures for $950,000,'' U.S. Department of
Health and Human Services (July 1, 2024), https://prod-wwwhhsgov.cloud.hhs.gov/about/news/2024/07/01/hhs-office-civil-rights-settles-hipaa-security-rule-failures-950000.html.
\537\ See ``Montefiore Medical Center,'' supra note 248.
\538\ See 45 CFR 164.308(a)(1)(ii)(D).
---------------------------------------------------------------------------
Similarly, a business associate experienced an intrusion into its
systems that it failed to notice for over 20 months. Eventually, the
ePHI of more than 200,000 individuals associated with several covered
entities was encrypted in a ransomware cyberattack.\539\ Among other
factors, OCR's investigation indicated that the business associate
potentially failed to implement procedures for regularly reviewing
records of activity in its relevant electronic information system, such
as audit logs, access reports, and security incident tracking
reports.\540\
---------------------------------------------------------------------------
\539\ See ``Doctors' Management Services, Inc.,'' supra note
246.
\540\ Id.
---------------------------------------------------------------------------
Consistent with previously issued guidance and based on OCR's
enforcement experience, the Department proposes to elevate the existing
implementation specification for information system activity review to
a standard and to redesignate it as proposed 45 CFR 164.308(a)(7)(i).
The purpose of the proposal is to impose specific requirements on a
regulated entity to review the activity occurring in its relevant
electronic information systems, including the activity occurring in the
components of such systems. By virtue of these proposed requirements,
we would specify actions that a regulated entity is required to take to
ensure that only appropriate users access ePHI and that it responds
quickly to any suspicious activity in its relevant electronic
information systems, including in components thereof, such as
workstations that connect to or otherwise access its relevant
electronic information systems. We also propose to revise the language
to provide regulated entities with additional direction regarding their
review of suspicious activities. The proposed standard, if adopted,
would require a regulated entity to implement written policies and
procedures for regularly reviewing
[[Page 947]]
records of activity in its relevant electronic information systems.
The Department proposes five implementation specifications for the
proposed standard for information system activity review. The proposed
implementation specification for policies and procedures at proposed 45
CFR 164.308(a)(7)(ii)(A) would require a regulated entity to establish
written policies and procedures for retaining and reviewing records of
activity in the regulated entity's relevant electronic information
systems by persons and technology assets. Such written policies and
procedures should require review of activity in the regulated entity's
relevant electronic information systems as a whole, as well as the
system's components, including but not limited to any workstations.
They should also include information on the frequency for reviewing
such records. The frequency of review may vary based on the specific
type of record being reviewed and the information it contains.
According to the proposed implementation specification for scope at
proposed 45 CFR 164.308(a)(7)(ii)(B), records of activity in the
regulated entity's relevant electronic information systems by persons
and technology assets would include, but would not be limited to, audit
trails, event logs, firewall logs, system logs, data backup logs,
access reports, anti-malware logs, and security incident tracking
reports. The proposed implementation specification for records review
at proposed 45 CFR 164.308(a)(7)(ii)(C) would require a regulated
entity to review records of activity in its relevant electronic
information systems by persons and technology assets as often as
reasonable and appropriate for the type of report or log. They would
also be required to document such review. A proposed implementation
specification for record retention at proposed 45 CFR
164.308(a)(7)(ii)(D) would require a regulated entity to retain records
of activity in its relevant electronic information systems by persons
and technology assets. Under the proposal, the regulated entity would
be required to retain such records for an amount of time that is
reasonable and appropriate for the specific type of report or log. For
example, it may be reasonable and appropriate to retain audit trails
for a different amount of time than security incident tracking reports
because of the type of information they contain and their purpose. The
proposed implementation specification for response at proposed 45 CFR
164.308(a)(7)(ii)(E) would require a regulated entity to respond to a
suspected or known security incident identified during the review of
activity in its relevant electronic information systems, including any
components thereof, such as workstations, in accordance with the
regulated entity's security incident plan.\541\ Finally, the proposed
implementation specification for maintenance at proposed 45 CFR
164.308(a)(7)(ii)(F) would require a regulated entity to review and
test its written policies and procedures for reviewing activity in its
relevant electronic information systems at least once every 12 months.
The regulated entity would be expected to modify such policies and
procedures as reasonable and appropriate, based on the results of that
review.
---------------------------------------------------------------------------
\541\ See proposed 45 CFR 164.308(a)(12)(ii)(B).
---------------------------------------------------------------------------
Consider a large regulated entity that may have thousands of
workforce members accessing various networks and relevant electronic
information systems, generating large amounts of log and audit data.
Given the size, complexity, and capabilities of entities of such size,
a reasonable and appropriate process for reviewing activity may include
the adoption of an automated solution that performs rules-based
enterprise log aggregation and analysis to identify anomalous or
suspicious patterns of behavior in the regulated entity's relevant
electronic information systems and the components thereof, including
but not limited to workstations, in real-time and sends alerts of
potential security incidents to a workforce member or team for further
review and action. By contrast, for a small regulated entity, it might
be reasonable and appropriate to have designated staff that manually
review log files and audit trails multiple times per week.
j. Section 164.308(a)(8)--Standard: Assigned Security Responsibility
The Department proposes to redesignate the standard for assigned
security responsibility at 45 CFR 164.308(a)(2) as proposed 45 CFR
164.308(a)(8). OCR's enforcement experience demonstrates that, in
practice, many regulated entities follow informal policies and
procedures that are not documented, and have not documented the
identification of the Security Official in writing.
Based on OCR's enforcement experience, and consistent with existing
guidance, we propose to modify the standard to specify that a regulated
entity must identify in writing the Security Official who is
responsible for the establishment and implementation of the policies
and procedures, whether written or otherwise, and deployment of
technical controls. These proposals are consistent with our general
intention in this NPRM to propose to clarify that policies and
procedures required by the Security Rule should be reduced to writing
and to distinguish between the implementation of written policies and
procedures and the deployment of technical controls.
As we previously explained in guidance,\542\ the purpose of this
standard is to identify who would be operationally responsible for
assuring that the regulated entity complies with the Security Rule. It
is comparable to the Privacy Rule standard for personnel designations
at 45 CFR 164.530(a)(1), which requires all covered entities to
designate a Privacy Official. The Security Official and Privacy
Official can, but need not be, the same person. While one workforce
member must be designated as having overall responsibility, other
workforce members may be assigned specific security responsibilities
(e.g., facility security, network security). When making this decision,
regulated entities should consider basic questions, such as: Has the
organization agreed upon, and clearly identified and documented, the
responsibilities of the Security Official? How are the roles and
responsibilities of the Security Official crafted to reflect the size,
complexity, and technical capabilities of the organization?
---------------------------------------------------------------------------
\542\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 7.
---------------------------------------------------------------------------
NIST guidance urges the regulated entity to select a workforce
member who is able to assess the effectiveness of security to serve as
the point of contact for security policy, implementation, and
monitoring.\543\ It further recommends that a regulated entity should
document the responsibilities in a job description and communicate this
assigned role to the entire organization. NIST provides additional
sample items for consideration by a regulated entity organizing its
security practices, including identifying the workforce members in the
organization who oversee the development and communication of security
policies and procedures, direct IT security purchasing and investment,
and ensure that security concerns have been addressed in system
implementation. NIST also offers that a regulated entity should ask
whether the security official has adequate access and communications
with senior officials in the organization and whether there is a
[[Page 948]]
complete job description that accurately reflects assigned security
duties and responsibilities.
---------------------------------------------------------------------------
\543\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
---------------------------------------------------------------------------
k. Section 164.308(a)(9)(i)--Standard: Workforce Security
The purpose of the workforce security standard is to ensure that
workforce members only have access to ePHI that they need to perform
their assigned functions and are prevented from accessing ePHI that
they are not authorized to access to perform such functions. The
proposed changes to the standard and implementation specifications
would clarify the actions required of a regulated entity to assure such
limits.
Individuals have been harmed in the past by the failure of
regulated entities to comply with the Security Rule requirements for
workforce security. For example, a former employee of a large covered
entity was able to access their former worksite and workstation using
still-active credentials for more than a week after their employment
was terminated.\544\ OCR's investigation found evidence of a potential
failure to terminate the former employee's access to PHI, which enabled
the former employee to download the ePHI of nearly 500 individuals,
including their names, addresses, dates of birth, race/ethnicity,
gender, and sexually transmitted infection test results onto a USB
drive. This type of real-world experience and OCR's observations more
broadly inform the changes proposed in this NPRM.
---------------------------------------------------------------------------
\544\ See Press Release, ``City Health Department failed to
terminate former employee's access to protected health
information,'' U.S. Department of Health and Human Services (Oct.
30, 2020), https://public3.pagefreezer.com/content/HHS.gov/31-12-2020T08:51/https://www.hhs.gov/about/news/2020/10/30/city-health-department-failed-terminate-former-employees-access-protected-health-information.html.
---------------------------------------------------------------------------
Moreover, this proposal is consistent with guidance issued by HHS
and NIST for implementing this standard and associated implementation
specifications. For example, in guidance issued in 2005, we explained
that regulated entities must identify workforce members who need access
to ePHI to carry out their duties.\545\ For each workforce member or
job function, the regulated entity must identify the ePHI that is
needed, when it is needed, and make reasonable efforts to control
access to the ePHI, a concept generally referred to as role-based
access (i.e., authorizing access to ePHI only when such access is
appropriate based on the workforce member's role).\546\ This also
includes identification of the computer systems and applications that
provide access to the ePHI. A regulated entity must provide only the
minimum necessary access to ePHI that is required for a workforce
member to do their job.\547\ As described in HHS guidance, access
authorization is the process of determining whether a particular user
(or a computer system) has the right, consistent with their function,
to carry out a certain activity, such as reading a file or running a
program.\548\ Implementation may vary among regulated entities,
depending on the size and complexity of their workforce, and their
electronic information systems that contain ePHI. For example, in a
small medical practice, all staff members may need to access all ePHI
in their information systems because each staff member may perform
multiple functions. In this case, the regulated entity would document
the reasons for implementing policies and procedures that permit this
type of global access. If the documented rationale is reasonable and
appropriate, this may be an acceptable approach. The implementation
specification provision for authorization and/or supervision provides
the necessary checks and balances to ensure that all members of the
workforce have appropriate access (or, in some cases, no access) to
ePHI.
---------------------------------------------------------------------------
\545\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 8-11.
\546\ See ``Summary of the HIPAA Security Rule,'' U.S.
Department of Health and Human Services (Oct. 19, 2022), https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html.
\547\ See 45 CFR 164.502(b) and 164.514(d).
\548\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 9.
---------------------------------------------------------------------------
NIST guidance provides descriptions of key activities and sample
questions for regulated entities implementing this implementation
specification.\549\ To implement procedures for the authorization and/
or supervision of workforce members who work with ePHI or in locations
where it might be accessed, the guidance advises regulated entities to
consider whether chains of command and lines of authority have been
established, as well as the identity and roles of supervisors. A
regulated entity also should establish clear job descriptions and
responsibilities, which includes defining roles and responsibilities
for all job functions; assigning appropriate levels of security
oversight, training, and access; and identifying in writing who has the
business need and who has been granted permission to view, alter,
retrieve, and store ePHI and at what times, under what circumstances,
and for what purposes.\550\ To determine the most reasonable and
appropriate authorization and/or supervision procedures, a regulated
entity must be able to answer some basic questions about existing
policies and procedures. For example, are detailed job descriptions
used to determine what level of access the person holding the position
should have to ePHI? Who has or should have the authority to determine
who can access ePHI, e.g., supervisors or managers? Are there written
job descriptions that are correlated with appropriate levels of access
to ePHI? Are these job descriptions reviewed and updated on a regular
basis? Have workforce members been provided copies of their job
descriptions and informed of the access granted to them, as well as the
conditions by which this access can be used? As noted above, a smaller
regulated entity may address compliance by implementing a simpler
approach, but it is still liable for ensuring that workforce members
only have access to ePHI that they need to perform their assigned
functions.\551\
---------------------------------------------------------------------------
\549\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\550\ See id. at 36.
\551\ See proposed 45 CFR 164.308(a)(9)(i).
---------------------------------------------------------------------------
NIST also recommends establishing criteria and procedures for
hiring and assigning tasks and ensuring that these requirements are
included as part of the personnel hiring process.\552\ In its guidance,
NIST provides questions and suggestions for regulated entities to
consider with respect to these criteria, procedures, and requirements.
NIST guidance also describes this implementation specification as
calling for regulated entities to implement appropriate screening of
persons who would have access to ePHI, and a procedure for obtaining
clearance from appropriate offices or workforce members where access is
provided or terminated.\553\ Similarly, the Department's guidance on
workforce clearance procedures states that the clearance process must
establish the procedures to verify that a workforce member would in
fact have the appropriate access for their job function.\554\ A
regulated entity may choose to perform this type of screening procedure
separate from, or as a part of, the authorization and/or supervision
procedure. Sample questions for
[[Page 949]]
regulated entities to consider include the following: Are there
existing procedures for determining that the appropriate workforce
members have access to the necessary information? Are the procedures
used consistently within the organization when determining access of
related workforce job functions? NIST guidance describes this
implementation specification as calling for regulated entities to
implement appropriate screening of persons who would have access to
ePHI, and a procedure for obtaining clearance from appropriate offices
or workforce members where access is provided or terminated.\555\
---------------------------------------------------------------------------
\552\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 36.
\553\ See id.
\554\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 10.
\555\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 37.
---------------------------------------------------------------------------
We issued guidance in 2017 addressing termination procedures.\556\
Data breaches caused by current and former workforce members are a
recurring issue across many industries, including the health care
industry. Effective identity and access management policies and
controls are essential to reduce the risks posed by these types of
insider threats. Identity and access management can include many
processes, but, most commonly, it would include the processes by which
appropriate access to data is granted and terminated by creating and
managing user accounts. Ensuring that user accounts are terminated--and
in a timely manner--so that former workforce members do not have access
to data, is one important way identity and access management can help
reduce risks posed by insider threats. Additionally, effective
termination procedures also reduce the risk that inactive user accounts
(e.g., user accounts that are not being used or are inactive but are
not fully terminated or disabled) could be used by a current or former
workforce member with malicious motives to get access to ePHI. The
Department's guidance also offers tips to prevent unauthorized access
to PHI by former workforce members, such as having standard procedures
of all action items to be completed when an individual leaves.\557\
---------------------------------------------------------------------------
\556\ See ``Insider Threats and Termination Procedures,''
Cybersecurity Newsletter, Office for Civil Rights, U.S. Department
of Health and Human Services (Nov. 2017), https://www.hhs.gov/sites/default/files/november-cybersecurity-newsletter-11292017.pdf.
\557\ See ``Managing Malicious Insider Threats,'' supra note
528.
---------------------------------------------------------------------------
Guidance that we issued in 2019 further explains that ``security is
a dynamic process.'' \558\ Good security practices entail continuous
awareness, assessment, and action in the face of changing
circumstances. The information users can and should be allowed to
access may change over time; organizations should recognize this in
their policies and procedures and in their implementation of those
policies and procedures. For example, if a user is promoted, demoted,
or transfers to a different department, a user's need to access data
may change. In such situations, the user's data access privileges
should be re-evaluated and, as needed, modified to match the new role,
if needed.\559\ As described in other HHS guidance, these procedures
should also address the complexity of the organization and the
sophistication of its relevant electronic information systems.\560\
---------------------------------------------------------------------------
\558\ Id.
\559\ See 45 CFR 164.308(a)(4)(ii)(C).
\560\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 10-11.
---------------------------------------------------------------------------
NIST guidance provides additional descriptions of key activities
and sample questions for regulated entities to consider when
implementing this standard and associated implementation
specifications.\561\ Regulated entities should establish a standard set
of procedures that should be followed to recover access control devices
(e.g., identification badges, keys, access cards) when employment ends
and, likewise, they should timely deactivate computer access (e.g.,
disable user IDs and passwords) and facility access (e.g., change
facility security codes/PINs). Sample questions for implementation
include the following: Are there separate procedures for voluntary
termination (e.g., retirement, promotion, transfer, change of
employment) versus involuntary termination (e.g., termination for
cause, reduction in force, involuntary transfer, criminal or
disciplinary actions)? Is there a standard checklist for all action
items that should be completed when a workforce member leaves (e.g.,
return of all access devices, deactivation of accounts, and delivery of
any needed data solely under the workforce member's control)? Do other
organizations need to be notified to deactivate accounts to which that
the workforce member had access in the performance of their employment
duties?
---------------------------------------------------------------------------
\561\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
---------------------------------------------------------------------------
However, regulated entities often do not establish or implement
written procedures, nor, even in instances where they have established
or implemented them, have they done so in an appropriate fashion to
protect ePHI from improper access by current or former workforce
members.
Consistent with the guidance described above and other proposals in
this NPRM, the Department proposes to redesignate the workforce
security standard at 45 CFR 164.308(a)(3)(i) as proposed 45 CFR
164.308(a)(9)(i), to add a paragraph heading to clarify the
organization of the regulatory text, and to modify the regulatory text
clarify that a regulated entity must implement written policies and
procedures ensuring that workforce members have appropriate access to
ePHI and to relevant electronic information systems. The regulated
entity must also implement written policies and procedures preventing
workforce members from accessing ePHI and relevant electronic
information systems if they are not authorized to do so. The
modifications we propose to the implementation specification for
authorization and/or supervision would clarify that a regulated entity
is required to establish and implement written procedures for the
authorization and/or supervision of workforce members who access ePHI
or relevant electronic information systems or who work in facilities
where ePHI or relevant electronic information systems might be
accessed.\562\ We propose similar modifications to the implementation
specification for workforce clearance procedure, which would require a
regulated entity to establish and implement written procedures to
determine that the access of a workforce member to ePHI or relevant
electronic information systems is appropriate, in accordance with
written policies and procedures for granting and revising access to
ePHI and relevant electronic information systems as required by
proposed 45 CFR 164.308(a)(10)(ii)(B).\563\ Additionally, we propose
several clarifications to the implementation specification for
termination procedures. Specifically, the proposed implementation
specification for modification and termination procedures at proposed
45 CFR 164.308(a)(9)(ii)(C) would require procedures for terminating a
workforce member's access to ePHI and relevant electronic information
systems, and to facilities where ePHI or relevant electronic
information systems might be accessed. Proposed paragraph
(a)(9)(ii)(C)(1) would require a regulated entity to establish and
implement written procedures for terminating a workforce member's
access to ePHI and relevant electronic information systems,
[[Page 950]]
and to locations where ePHI or relevant electronic information systems
might be accessed. Proposed paragraph (a)(9)(ii)(C)(2) would require
that the workforce member's access be terminated as soon as possible,
but no later than one hour after the workforce member's employment or
other arrangement ends. A proposed implementation specification for
notification at proposed 45 CFR 164.308(a)(9)(ii)(D) would require a
regulated entity to establish and implement written procedures for
notifying another regulated entity of a change in, or termination of, a
workforce member's authorization to access ePHI or relevant electronic
information systems. Proposed paragraph (a)(9)(ii)(D)(1) would require
the regulated entity to establish and implement written procedures for
notifying another regulated entity after a change in or termination of
a workforce member's authorization to access ePHI or relevant
electronic information systems that are maintained by such other
regulated entity where the workforce member is or was authorized to
access such ePHI or relevant electronic information systems by the
regulated entity making the notification. Proposed paragraph
(a)(9)(ii)(D)(2) would require the notice to be provided as soon as
possible, but no later than 24 hours after the workforce member's
authorization to access ePHI or relevant electronic information systems
is changed or terminated. Finally, a proposed new implementation
specification for maintenance at proposed 45 CFR 164.308(a)(9)(ii)(E)
would require a regulated entity to review and test its written
workforce security policies and procedures at least once every 12
months and to modify them as reasonable and appropriate.\564\ The
proposed implementation specifications for termination procedures and
notification implementation align with the Department's essential CPG
for Revoke Credentials for Departing Workforce Members, Including
Employees, Contractors, Affiliates, and Volunteers by requiring a
regulated entity to promptly remove access following a change in or
termination of a user's authorization to access ePHI.\565\
---------------------------------------------------------------------------
\562\ See proposed 45 CFR 164.308(a)(9)(ii)(A).
\563\ See proposed 45 CFR 164.308(a)(9)(ii)(B).
\564\ See proposed 45 CFR 164.308(a)(9)(ii)(E).
\565\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
l. Section 164.308(a)(10)(i)--Standard: Information Access Management
The purpose of the standard for information access management is to
protect ePHI by reducing the risk that other persons or technology
assets may access the information for their own reasons. Existing HHS
guidance explains that restricting access to only those persons and
entities with a need for access is a basic tenet of security.\566\ By
implementing this standard, the risk of inappropriate disclosure,
alteration, or destruction of ePHI is minimized. A regulated entity
must determine those persons and technology assets that need access to
ePHI within its environment. The implementation specifications
associated with the standard on information access management are
closely related to those associated with the standard for workforce
security.\567\ Compliance with the proposed and existing standards for
information access management should support a regulated entity's
compliance with the Privacy Rule's minimum necessary requirements,
which requires a regulated entity to evaluate its practices and enhance
safeguards as needed to limit unnecessary or inappropriate access to
and disclosure of PHI.\568\
---------------------------------------------------------------------------
\566\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p.11.
\567\ See, e.g., Resolution Agreement, ``Banner Health,'' Office
for Civil Rights, U.S. Department of Health and Human Services (Dec.
20, 2022), https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/banner-health-ra-cap/index.html; ``Montefiore
Medical Center,'' supra note 248.
\568\ See 45 CFR 164.502(b) and 164.514(d).
---------------------------------------------------------------------------
OCR's enforcement experience demonstrates that many regulated
entities have not adequately implemented this standard. Thus, we
believe it is necessary to consider strengthening the requirement. For
example, on one occasion, a large covered entity's failure to implement
its written policies and procedures to ensure that employees only had
access to ePHI that they had proper authorization or authority to
access enabled an employee to access the ePHI of more than 24,000
individuals.\569\ This failure also enabled other employees to
inappropriately access the ePHI of a celebrity.\570\
---------------------------------------------------------------------------
\569\ See Press Release, ``OCR Imposes a $2.15 Million Civil
Money Penalty against Jackson Health System for HIPAA Violation,''
U.S. Department of Health and Human Services (Oct. 19, 2019),
https://public3.pagefreezer.com/browse/HHS.gov/31-12-2020T08:51/https://www.hhs.gov/about/news/2019/10/23/ocr-imposes-a-2.15-million-civil-money-penalty-against-jhs-for-hipaa-violations.html;
see also Notice of Proposed Determination, ``Jackson Health
System,'' Office for Civil Rights, U.S. Department of Health and
Human Services (July 22, 2019), https://public3.pagefreezer.com/browse/HHS.gov/31-12-2020T08:51/https://www.hhs.gov/sites/default/files/jackson-health-system-notice-of-final-determination_508.pdf;
Notice of Final Determination, ``Jackson Health System,'' Office for
Civil Rights, U.S. Department of Health and Human Services (Oct. 15,
2019), https://public3.pagefreezer.com/browse/HHS.gov/31-12-2020T08:51/https://www.hhs.gov/sites/default/files/jackson-health-system-notice-of-final-determination_508.pdf.
\570\ See Press Release, ``HHS Office for Civil Rights Settles
HIPAA Investigation with Arizona Hospital System Following
Cybersecurity Hacking,'' U.S. Department of Health and Human
Services (Feb. 2, 2023), https://www.hhs.gov/about/news/2023/02/02/hhs-office-for-civil-rights-settles-hipaa-investigation-with-arizona-hospital-system.html.
---------------------------------------------------------------------------
To ensure that regulated entities implement recommendations and
best practices for securing ePHI, we propose to require in the standard
for information access management and associated implementation
specifications that a regulated entity must establish and implement
written policies and procedures for authorizing access to ePHI and
relevant electronic information systems that are consistent with the
Privacy Rule. The Department also proposes to redesignate the standard
at 45 CFR 164.308(a)(4)(i) as proposed 45 CFR 164.308(a)(10)(i) and to
add a paragraph heading to clarify the organization of the regulatory
text. Additionally, the Department proposes to modify three of the
associated existing implementation specifications and to add three new
implementation specifications as follows.
Specifically, the Department proposes to redesignate the
implementation specification for isolating health care clearinghouse
functions as proposed 45 CFR 164.308(a)(10)(ii)(A) and to modify it to
require a health care clearinghouse that is part of a larger
organization to establish and implement written policies and procedures
that protect the ePHI and relevant electronic information systems of
the clearinghouse from unauthorized access by the larger organization.
The existing implementation specification for isolating health care
clearinghouse functions only applies in the situation where a health
care clearinghouse is part of a larger organization. This would remain
true under the proposal to revise this implementation specification, if
adopted. In these situations, the health care clearinghouse is
responsible for protecting the ePHI that it is creating, receiving,
maintaining, and transmitting. As discussed in NIST guidance, if a
health care clearinghouse is part of a larger organization, the
clearinghouse must implement policies and procedures that protect the
ePHI of the clearinghouse from unauthorized access by the larger
organization.\571\ This necessarily includes its relevant electronic
information systems. First, the regulated entity must determine
[[Page 951]]
whether any of its components constitute a health care clearinghouse
under the Security Rule.\572\ If no health care clearinghouse functions
exist within the organization, the regulated entity should document
this finding. If a health care clearinghouse does exist within the
organization, the regulated entity must implement procedures that are
consistent with the Privacy Rule.\573\ Questions for regulated entities
to consider include: If health care clearinghouse functions are
performed, are policies and procedures implemented to protect ePHI from
the other functions of the larger organization? Does the health care
clearinghouse share hardware or software with a larger organization of
which it is a part? Does the health care clearinghouse share staff or
physical space with staff from a larger organization? Has a separate
network or subsystem been established for the health care
clearinghouse, if reasonable and appropriate? Has staff of the health
care clearinghouse been trained to safeguard ePHI from disclosure to
the larger organization, if required for compliance with the Privacy
Rule? \574\ Regulated entities should also consider whether additional
technical safeguards are needed to separate ePHI in electronic
information systems used by the health care clearinghouse to protect
against unauthorized access by the larger organization.
---------------------------------------------------------------------------
\571\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\572\ 45 CFR 160.103 (definition of ``Health care
clearinghouse'').
\573\ 45 CFR 164.500(b); see also ``Implementing the Health
Insurance Portability and Accountability Act (HIPAA) Security Rule:
A Cybersecurity Resource Guide,'' supra note 461, p. 38.
\574\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 38.
---------------------------------------------------------------------------
We also propose to redesignate the implementation specification for
access authorization as proposed 45 CFR 164.308(a)(10)(ii)(B) and to
modify it to emphasize that a regulated entity must establish and
implement written policies and procedures for granting and revising
access to ePHI and the regulated entity's relevant electronic
information systems as necessary and appropriate for each prospective
user and technology asset to carry out their assigned function(s)
(i.e., role-based access policies). Additionally, we propose to
redesignate the implementation specification for access establishment
and modification as 45 CFR 164.308(a)(10)(ii)(D) and to modify the
heading to ``Access determination and modification.'' We also propose
to modify this implementation specification to require a regulated
entity to establish and implement written policies and procedures that,
based on its access authorization policies, establish, document,
review, and modify the access of each user and technology asset to
specific components of the regulated entity's relevant electronic
information systems. Such written policies and procedures would be
required to be based upon the regulated entity's policies for
authorizing access. Under this proposal, and consistent with the
existing implementation specification,\575\ the regulated entity would
be required to establish standards for granting access to ePHI and
relevant electronic information systems and provide formal
authorization from the appropriate authority before granting access to
ePHI or relevant electronic information systems. Regulated entities
should regularly review personnel access to ePHI and relevant
electronic information systems to ensure that access is still
authorized and needed, and modify personnel access to ePHI and
electronic information systems, as needed, based on review activities.
---------------------------------------------------------------------------
\575\ 45 CFR 164.308(a)(4)(ii)(C).
---------------------------------------------------------------------------
The existing implementation specification for access authorization
calls for the regulated entity to implement policies and procedures for
granting access to ePHI, for example, through components of its
information system.\576\ The Department's proposal to revise this
implementation specification would provide greater specificity than our
existing requirements, and echo NIST guidance on this topic.
Specifically, NIST guidance \577\ describes the key steps for
developing policies and procedures for granting access to ePHI as
follows:
---------------------------------------------------------------------------
\576\ 45 CFR 164.308(a)(4)(ii)(B).
\577\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
---------------------------------------------------------------------------
Decide and document procedures for how access to ePHI
would be granted to workforce members within the organization.
Select the basis for restricting access to ePHI. Select an
access control method (e.g., identity-based, role based, or other
reasonable and appropriate means of access).
Decide and document how access to ePHI would be granted
for privileged functions.
Ensure that there is a list of personnel with authority to
approve user requests to access ePHI and systems with ePHI.
Identify authorized users with access to ePHI, including
data owners and data custodians.
Consider whether multiple access control methods are
needed to protect ePHI according to the results of the risk assessment.
Determine whether direct access to ePHI would ever be
appropriate for individuals external to the organization (e.g.,
business partners or patients seeking access to their own ePHI).
Other questions that a regulated entity should consider when
establishing such policies and procedures include: Have appropriate
authorization and clearance procedures, as specified in the standard
for workforce security,\578\ been performed prior to granting access?
Do the organization's systems have the capacity to set access controls?
Are there additional access control requirements for users who would be
accessing privileged functions? Have organizational personnel been
explicitly authorized to approve user requests to access ePHI and/or
systems with ePHI?
---------------------------------------------------------------------------
\578\ See 45 CFR 164.308(a)(3); proposed 45 CFR
164.308(a)(9)(i).
---------------------------------------------------------------------------
The Department proposes three additional implementation
specifications for authentication management, maintenance, and network
segmentation. These specifications clarify the Department's
expectations for compliance and are consistent with NIST guidance. We
believe that the proposed additions would assist regulated entities in
their efforts to prevent or mitigate attacks by malicious internal and
external actors. For the implementation specification on authentication
management at proposed 45 CFR 164.308(a)(10)(ii)(C), we propose to
require a regulated entity to establish and implement written policies
and procedures for verifying the identities of users and technology
assets before accessing the regulated entity's relevant electronic
information systems, including written policies and procedures for
implementing MFA technical controls.\579\ The proposed implementation
specification for network segmentation at proposed 45 CFR
164.308(a)(10)(ii)(E) would require a regulated entity to establish and
implement written policies and procedures that ensure that its relevant
electronic information systems are segmented to limit access to ePHI to
authorized workstations.
---------------------------------------------------------------------------
\579\ See proposed 45 CFR 164.312(f)(2)(ii) through (iv).
---------------------------------------------------------------------------
Finally, to address the Department's general concerns regarding the
ongoing failure of many regulated entities to regularly review and
revise their policies and procedures, the proposed implementation
specification for maintenance at proposed 45 CFR
[[Page 952]]
164.308(a)(10)(ii)(F) would require a regulated entity to review the
written policies and procedures required by this standard at least once
every 12 months and to modify them as reasonable and appropriate.
m. Section 164.308(a)(11)(i)--Standard: Security Awareness Training
A covered entity's workforce is its frontline not only in patient
care and patient service, but also in safeguarding the privacy and
security of PHI.\580\ The health care sector's risk landscape continues
to grow with the increasing number of interconnected, smart devices of
all types, the increased use of interconnected medical record and
billing systems, and the increased use of applications and cloud
computing. This standard reflects the fact that training on data
security for workforce members is essential for protecting an
organization against cyberattacks.
---------------------------------------------------------------------------
\580\ See ``Train Your Workforce, so They Don't Get Caught by a
Phish!,'' Cybersecurity Newsletter, Office for Civil Rights, U.S.
Department of Health and Human Services (July 2017), https://www.hhs.gov/sites/default/files/july-2017-ocr-cyber-newsletter.pdf.
---------------------------------------------------------------------------
An organization's training program should be an ongoing, evolving
process and flexible enough to educate workforce members on new
cybersecurity threats and how to respond to them. As such, regulated
entities should consider how often to train workforce members on
security issues, given the risks and threats to their enterprises, and
how often to send security updates to their workforce members. Many
regulated entities have determined that twice-annual training and
monthly security updates are necessary, given their risks analyses.
Regulated entities should apply security updates and reminders to
quickly communicate new and emerging cybersecurity threats to workforce
members such as new social engineering ploys (e.g., fake tech support
requests and new phishing scams) and malicious software attacks
including new ransomware variants. Entities need to address what type
of training to provide to workforce members on security issues, given
the risks and threats to their enterprises. Computer-based training,
classroom training, monthly newsletters, posters, email alerts, and
team discussions are all tools that different organizations use to
fulfill their training requirements. Entities must also address how to
document that training to workforce members was provided, including
dates and types of training, training materials, and evidence of
workforce participation.
HHS has issued many types of training materials on securing
PHI.\581\ NIST has also provided detailed guidance for developing and
implementing workforce training programs.\582\ Despite this existing
guidance, regulated entities often fail to provide appropriate training
to adequately safeguard ePHI. For example, in one investigation, OCR
investigators found evidence that not only had an ambulance company
potentially failed to conduct a risk analysis, it also potentially
failed to implement a security training program or to train any of its
employees.\583\ Such failures can contribute to breaches of
individuals' unsecured ePHI.
---------------------------------------------------------------------------
\581\ See ``Training Materials,'' Office for Civil Rights, U.S.
Department of Health and Human Services, https://www.hhs.gov/hipaa/for-professionals/training/index.html.
\582\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\583\ See Resolution Agreement, ``West Georgia Ambulance, Inc.''
Office for Civil Rights, U.S. Department of Health and Human
Services (Dec. 23, 2019), https://www.hhs.gov/sites/default/files/west-georgia-ra-cap.pdf.
---------------------------------------------------------------------------
To ensure security awareness training compliance, a regulated
entity needs to regularly educate its workforce members on the evolving
technological threats to ePHI, how to use the technology that the
regulated entity has adopted and implemented, and the specific
procedures workforce members must follow to ensure that the ePHI
remains protected. Additionally, while many educational programs for
clinicians provide general training on the HIPAA Rules, the curriculums
vary widely. Without providing its own training on the Security Rule, a
regulated entity cannot ensure that the training its workforce received
elsewhere meets the required standards.
Given the failure of regulated entities to implement the security
awareness and training standard and consistent with existing guidance,
the Department proposes to provide more detailed requirements for
security awareness training. Specifically, the Department proposes to
rename and redesignate the standard for security awareness and training
at 45 CFR 164.308(a)(5)(i) as the standard for security awareness
training at proposed 45 CFR 164.308(a)(11)(i) and to add a paragraph
heading to clarify the organization of the regulatory text. The
proposed standard would require a regulated entity to implement
security awareness training for all workforce members on protection of
ePHI and information systems as necessary and appropriate for the
members of the workforce to carry out their assigned function(s) (i.e.,
role-based training). The proposals to revise this standard would also
align with the Department's essential CPG for Basic Cybersecurity
Training because they would require a regulated entity to educate users
on how to access ePHI and electronic information systems in a manner
that protects the confidentiality, integrity, and availability of
ePHI.\584\ Additionally, the proposals would align with the essential
CPG for Email Security by requiring a regulated entity to train
workforce members to guard against, detect, and report suspected or
known security incidents, including, but not limited to, malicious
software and social engineering.\585\
---------------------------------------------------------------------------
\584\ ``Cybersecurity Performance Goals,'' supra note 18.
\585\ Id.
---------------------------------------------------------------------------
We propose four implementation specifications for the proposed
security awareness training standard. The proposed implementation
specification for training at 45 CFR 164.308(a)(11)(ii)(A) would
require a regulated entity to establish and implement security
awareness training for all workforce members that addresses the
following:
The written policies and procedures required by the
Security Rule, as necessary and appropriate for the workforce members
to carry out their assigned functions.\586\
---------------------------------------------------------------------------
\586\ Proposed 45 CFR 164.308(a)(11)(ii)(A)(1).
---------------------------------------------------------------------------
Guarding against, detecting, and reporting suspected or
known security incidents, including but not limited to malicious
software and social engineering.\587\
---------------------------------------------------------------------------
\587\ Proposed 45 CFR 164.308(a)(11)(ii)(A)(2).
---------------------------------------------------------------------------
The written policies and procedures for accessing the
regulated entity's electronic information systems, including, but not
limited to, safeguarding passwords, setting unique passwords of
sufficient strength to ensure the confidentiality, integrity, and
availability of ePHI, and establishing limitations on sharing
passwords. Consistent with the recommendation from NCVHS, such policies
and procedures should ensure that the regulated entity does not employ
default passwords and should prevent workforce members from sharing of
credentials.\588\ We do not propose that passwords be required to meet
a particular standard because best practices for password configuration
may change over time; however, we believe that it is essential for a
regulated
[[Page 953]]
entity to educate its workforce members on best practices for setting
passwords and to ensure that its workforce members implement such best
practices.
---------------------------------------------------------------------------
\588\ Proposed 45 CFR 164.308(a)(11)(ii)(A)(3); Letter from
NCVHS Chair Jacki Monson (2023), supra note 123, Appendix p. 1;
Letter from NCVHS Chair Jacki Monson (2022), supra note 123, p. 6-7.
---------------------------------------------------------------------------
The Department proposes to replace the implementation specification
for periodic security updates \589\ with one addressing the timing and
frequency of security awareness training at proposed 45 CFR
164.308(a)(11)(ii)(B). Specifically, we propose to require a regulated
entity to provide such training to each member of the regulated
entity's workforce by the compliance date for this rulemaking, if
finalized, and at least once every 12 months thereafter.\590\ For
example, under this proposal, workforce members would receive security
awareness training on the protection of ePHI and on the regulated
entity's Security Rule policies and procedures that is based on their
specific role at least once a year. A regulated entity would be
required to provide role-based security awareness training to a new
workforce member within a reasonable period of time, but no later than
30 days after the workforce member first has access to the regulated
entity's relevant electronic information systems.\591\ We also propose
to require that the regulated entity provide such training.\592\ For
example, if the entity implements a new EHR system, it would be
required to also train its workforce, as appropriate, on measures to
guard against security incidents related to the installation,
maintenance and/or use of the system.
---------------------------------------------------------------------------
\589\ 45 CFR 164.308(a)(5)(ii)(A).
\590\ Proposed 45 CFR 164.308(a)(11)(ii)(B)(1).
\591\ Proposed 45 CFR 164.308(a)(11)(ii)(B)(2).
\592\ Proposed 45 CFR 164.308(a)(11)(ii)(B)(3).
---------------------------------------------------------------------------
Additionally, the Department proposes at proposed 45 CFR
164.308(a)(11)(ii)(C) an implementation specification for ongoing
education. This would require a regulated entity to provide its
workforce members with ongoing reminders of their security
responsibilities and notice of relevant threats, including but not
limited to, new and emerging malicious software and social engineering.
Lastly, we propose a new implementation specification for documentation
at proposed 45 CFR 164.308(a)(11)(ii)(D) that would require a regulated
entity to document that it has provided training and ongoing reminders
to its workforce members.
n. Section 164.308(a)(12)(i)--Standard: Security Incident Procedures
Addressing security incidents is an integral part of an overall
security program. While a regulated entity will never be able to
prevent all security incidents, implementing the Security Rule
standards would reduce the amount and negative consequences of security
incidents it encounters. Even regulated entities with detailed security
policies and procedures and advanced technology may experience security
incidents, but through sufficient planning and continued monitoring
generally can mitigate the negative effects of such incidents on
regulated entities, and, ultimately, individuals. The security incident
procedures standard is intended to help ensure that a regulated entity
conducts such planning and monitoring to allow it to mitigate such
negative effects.
The Department has also provided guidance that a regulated entity
can use to devise its security incident plans. The policies and
procedures a regulated entity establishes to prepare for and respond to
security incidents can pay dividends with faster recovery times and
reduced compromises of ePHI.\593\ A well thought-out, well-tested
security incident response plan is integral to ensuring the
confidentiality, integrity, and availability of a regulated entity's
ePHI. A timely response to a security incident can be one of the best
ways to prevent, mitigate, and recover from future cyberattacks. For
example, responding to a single intrusion or inappropriate access can
prevent a pattern of repeated malicious actions. It is extremely
important that a regulated entity analyzes an incident to establish
what has occurred and its root cause. Doing so will enable the
regulated entity to use that information to update its security
incident response plans. The Department has previously issued guidance
addressing such activities as forming a security incident response
team, identifying and responding to security incidents, mitigating
harmful effects of and documenting a security incident, and breach
reporting.\594\
---------------------------------------------------------------------------
\593\ See ``HIPAA Security Rule Security Incident Procedures,''
Cybersecurity Newsletter, Office for Civil Rights U.S. Department of
Health and Human Services (Oct. 2022), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-october-2022/index.html.
\594\ Id.
---------------------------------------------------------------------------
NIST also offers guidance for addressing security incidents.\595\
It describes four key activities with detailed descriptions and sample
questions:
---------------------------------------------------------------------------
\595\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
---------------------------------------------------------------------------
Determine the goals of an incident response.
Develop and deploy an incident response team or other
reasonable and appropriate response mechanism.
Develop and implement policy and procedures to respond to
and report security incidents.
Incorporate post-incident analysis into updates and
revisions.
NIST has also issued comprehensive guidelines for incident
handling, particularly for analyzing incident related data and
determining the appropriate response to each incident.\596\ For
example, the NIST Cybersecurity Framework addresses these activities as
part of the core function of ``[respond--a]ctions regarding a detected
cybersecurity incident are taken.'' \597\ ``Respond'' supports the
ability of the regulated entity ``to contain the effects of
cybersecurity incidents. Outcomes within this Function [include]
incident management, analysis, mitigation, reporting, and
communication.'' \598\
---------------------------------------------------------------------------
\596\ See Paul Cichonski, et al., ``Computer Security Incident
Handling Guide: Recommendations of the National Institute of
Standards and Technology,'' NIST Special Publication 800-61,
Revision 2, National Institute of Standards and Technology, U.S.
Department of Commerce (Aug. 2012), https://www.nist.gov/privacy-framework/nist-sp-800-61.
\597\ ``The NIST Cybersecurity Framework (CSF) 2.0,'' (removed
emphasis on ``Actions regarding a detected cybersecurity incident
are taken'' in original), supra note 15, p. 9.
\598\ Id.
---------------------------------------------------------------------------
Despite this existing guidance, OCR's enforcement experience
indicates that many regulated entities have not met the existing
standard, so we believe that additional specificity regarding their
obligations and liability for incident response is warranted.
Accordingly, the Department proposes to redesignate the standard for
security incident procedures as 45 CFR 164.308(a)(12)(i), to add a
paragraph heading to clarify the organization of the regulatory text,
and to modify the regulatory text to clarify that a regulated entity
would be required to implement written policies and procedures to
``respond to,'' rather than ``address,'' security incidents.
Additionally, we propose to clarify expectations by adding an
implementation specification for planning and testing at proposed 45
CFR 164.308(a)(12)(ii)(A)(1) that would require a regulated entity to
establish written security incident response plan(s) and procedures
documenting how workforce members are to report suspected or known
security incidents and how the regulated entity will respond to
suspected or known security incidents.\599\
---------------------------------------------------------------------------
\599\ Proposed 45 CFR 164.308(a)(12)(ii)(A)(1).
---------------------------------------------------------------------------
Internal reporting is an essential component of security incident
procedures.\600\ Plans and procedures for
[[Page 954]]
reporting of suspected or known security incidents may address to whom,
when, and how such incidents are to be reported. The recipient(s) and
the content of such reports, according to such plans and procedures,
may vary based on the type of incident and the role of the workforce
member making the report. We do not propose to dictate the form,
format, or content of such report. Rather, we believe that regulated
entities would be best situated to identify the point(s) of contact for
their organization (e.g., Chief Information Security Officer, IT
security team, business associate engaged to support incident response
activities for the regulated entity) for such reports and the type of
information they need to determine how to respond to the suspected or
known security incident.
---------------------------------------------------------------------------
\600\ See, e.g., Joint Task Force, ``Security and Privacy
Controls for Information Systems and Organizations,'' NIST Special
Publication 800-53, Revision 5, National Institute of Standards and
Technology, U.S. Department of Commerce, p. 157 (Sept. 2020),
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf.
---------------------------------------------------------------------------
The proposal to require a regulated entity to establish written
security incident response plans and procedures for how it will respond
to suspected or known security incidents would align with the enhanced
CPG for Third Party Incident Reporting because it would address the
procedures for how and when a business associate would report to a
covered entity or another business associate known or suspected
security incidents, as required by proposed 45 CFR
164.314(a)(2)(i)(C).\601\
---------------------------------------------------------------------------
\601\ ``Cybersecurity Performance Goals,'' supra note 18; see
also proposed 45 CFR 164.314(a)(2)(i)(C).
---------------------------------------------------------------------------
Under proposed 45 CFR 164.308(a)(12)(ii)(A)(2) and (3), the
regulated entity would be required to implement written procedures for
testing and revising the security incident response plan(s) and then,
using those written procedures, review and test its security incident
response plans at least once every 12 months and document the results
of such tests. The regulated entity would also be required to modify
the plan(s) and procedures as reasonable and appropriate, based on the
results of such tests and the regulated entity's circumstances.
This proposal, if finalized, would include requirements that align
with the Department's essential CPG for Basic Incident Planning and
Preparedness to have effective responses to and recovery from security
incidents.\602\ It also aligns with the Department's enhanced CPG for
Centralized Incident Planning and Preparedness by requiring a regulated
entity to maintain, revise, and test security incident response
plans.\603\
---------------------------------------------------------------------------
\602\ ``Cybersecurity Performance Goals,'' supra note 18.
\603\ Id.
---------------------------------------------------------------------------
Additionally, the Department proposes to redesignate the
implementation specification for response and reporting at 45 CFR
164.308(a)(6)(ii) as 45 CFR 164.308(a)(12)(ii)(B) and to rename it
``Response.'' We also propose to modify the existing implementation
specification by separating it into two paragraphs: one at paragraph
(a)(12)(ii)(B)(1) for identifying and responding to suspected or known
security incidents, and the other at paragraph (a)(12)(ii)(B)(2) for
mitigating, to the extent practicable, the harmful effects of suspected
or known security incidents. The Department also proposes to add three
additional paragraphs to this implementation specification. Proposed 45
CFR 164.308(a)(12)(ii)(B)(3) would require a regulated entity to
identify and remediate, to the extent practicable, the root cause(s) of
suspected or known security incidents, while proposed 45 CFR
164.308(a)(12)(ii)(B)(4) would require the regulated entity to
eradicate the security incidents that are suspected or known to the
regulated entity. We would expect eradication to include the removal of
malicious software, inappropriate materials, and any other components
of the incident from the regulated entity's relevant electronic
information systems.\604\ Finally, proposed 45 CFR
164.308(a)(12)(ii)(B)(5) would require a regulated entity to develop
and maintain documentation of investigations, analyses, mitigation, and
remediation for security incidents that are suspected or known. For
example, verbal reports of a suspected or known security incident would
be required to be documented in writing. Under proposed 45 CFR
164.316(b)(1), if finalized, a regulated entity would be required to
maintain such documentation for six years from the date of its creation
or the date when it last was in effect, whichever is later. These
proposals are consistent with existing guidance described above and
with other proposals or existing regulatory standards to secure health
information.\605\
---------------------------------------------------------------------------
\604\ See ``Computer Security Incident Handling Guide:
Recommendations of the National Institute of Standards and
Technology,'' supra note 597.
\605\ See, e.g., ``New York State Register,'' supra note 14;
``Invitation for Preliminary Comments on Proposed Rulemaking:
Cybersecurity Audits, Risk Assessments, and Automated
Decisionmaking,'' supra note 14; see also Cal. Civ. Code Section
1798.185.
---------------------------------------------------------------------------
o. Section 164.308(a)(13)(i)--Standard: Contingency Plan
The purpose of any contingency plan is to allow an organization to
return to its daily operations as quickly as possible after an
unforeseen event.\606\ The contingency plan protects resources,
minimizes customer inconvenience, and identifies key staff, assigning
specific responsibilities in the context of the recovery. Contingency
plans are critical to protecting the availability, integrity, and
security of data during unexpected adverse events. Contingency plans
should consider not only how to respond to disasters such as fires and
floods, but also how to respond to cyberattacks. Cyberattacks using
malicious software, such as ransomware, may render an organization's
data unreadable or unusable. In the event data is compromised by a
cyberattack, restoring the data from backups may be the only option for
recovering the data and restoring normal business operations. For
example, the faulty software update by CrowdStrike made it impossible
for health care systems worldwide to use their Windows-based
systems.\607\ There were many instances where surgical procedures and
health care appointments were cancelled, schedules upended, and
pharmacies were unable to fill prescriptions. Regulated entities need
to make and implement contingency plans they would use when such events
occur to enable themselves to get back to their core functions of
providing or paying for health care.
---------------------------------------------------------------------------
\606\ See ``Plan A. . .B. . .Contingency Plan!'' Cybersecurity
Newsletter, Office for Civil Rights, U.S. Department of Health and
Human Services (Mar. 2018), https://www.hhs.gov/sites/default/files/march-2018-ocr-cyber-newsletter-contingency-planning.pdf.
\607\ See Kate Conger, et al., ``What Is Crowdstrike?,'' New
York Times (July 19, 2024), https://www.nytimes.com/2024/07/19/business/what-is-crowdstrike.html?searchResultPosition=2; see also
``Remediation and Guidance Hub: Falcon Content Update for Windows
Hosts,'' (July 31, 2024), https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/.
---------------------------------------------------------------------------
The Department and NIST have issued extensive guidance on
contingency planning, including detailed descriptions of key
activities, sample questions for regulated entities to consider when
standing up a contingency plan, and information on how the results of
the risk analysis feed into contingency plans.\608\ Unfortunately, many
regulated entities have not implemented the required
[[Page 955]]
planning and then have been unable to fully recover from ransomware
attacks that bring down electronic systems that create, receive,
maintain, or transmit ePHI. For example, a large health system that
experienced a ransomware attack had to shut down services at multiple
locations and encountered difficulties restoring those services. OCR's
investigation indicated a potential failure to, among other things,
implement contingency plans.\609\ Such planning is crucial for
maintaining the resilience of a regulated entity's health IT.
---------------------------------------------------------------------------
\608\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461; see also ``Security Standards:
Administrative Safeguards,'' supra note 517, p. 19-22.
\609\ See Press Release, ``HHS Office for Civil Rights Settles
HIPAA Security Rule Failures for $950,000,'' U.S. Department of
Health and Human Services (July 1, 2024), https://prod-wwwhhsgov.cloud.hhs.gov/about/news/2024/07/01/hhs-office-civil-rights-settles-hipaa-security-rule-failures-950000.html.
---------------------------------------------------------------------------
To address these inadequacies in compliance and to protect the
confidentiality, integrity, and availability of ePHI, the Department
proposes to redesignate the standard for a contingency plan at 45 CFR
164.308(a)(7)(i) as proposed 45 CFR 164.308(a)(13)(i), to add a
paragraph heading to clarify the organization of the regulatory text,
and to modify the regulatory text to clarify it. The modified standard,
as proposed, would require a regulated entity to establish (and
implement as needed) a written contingency plan, consisting of written
policies and procedures for responding to an emergency or other
occurrence, including, but not limited to, fire, vandalism, system
failure, natural disaster, or security incident, that adversely affects
relevant electronic information systems.
The Department proposes a new implementation specification for
criticality analysis at proposed 45 CFR 164.308(a)(13)(ii)(A). This
would require a regulated entity to perform and document an assessment
of the relative criticality of its relevant electronic information
systems and technology assets in its relevant electronic information
systems. The proposal would not limit this analysis to electronic
information systems that create, receive, maintain, or transmit ePHI
because other electronic information systems and/or technology assets
may be crucial to ensuring the confidentiality, integrity, or
availability of ePHI, providing patient care, and supporting other
business needs. A prioritized list of specific relevant electronic
information systems and technology assets in those electronic
information systems would help a regulated entity to determine their
criticality and the order of restoration.\610\
---------------------------------------------------------------------------
\610\ See ``Security Standards: Administrative Safeguards,''
supra note 517, p. 22.
---------------------------------------------------------------------------
Under this proposal, the implementation specification for
establishing and implementing a data backup plan would be redesignated
as proposed 45 CFR 164.308(a)(13)(ii)(B) and renamed ``Data backups.''
It would also be modified to clarify that the procedures to create and
maintain exact retrievable copies of ePHI must be in writing, and to
also require such procedures to include verifying that the ePHI has
been copied accurately. For example, the ability to access ePHI from a
remote location in the event of a total failure should be reflected in
the procedures specified for data backups.
The proposed implementation specification for backing up
information systems at proposed paragraph (a)(13)(ii)(C) would require
a regulated entity to establish and implement written procedures to
create and maintain backups of its relevant electronic information
systems, including verifying the success of such backups. Establishing
such procedures would ensure that the ePHI in relevant electronic
information systems is both protected and available.
Additionally, the Department proposes to redesignate the
implementation specification for disaster recovering planning as
paragraph (a)(13)(ii)(D). We propose to clarify that a regulated entity
would be required to establish (and implement as needed) written
procedures to restore both its critical relevant electronic information
systems and data within 72 hours of the loss, and to restore the loss
of other relevant electronic information systems and data in accordance
with its criticality analysis.\611\
---------------------------------------------------------------------------
\611\ See proposed 45 CFR 164.308(a)(13)(ii)(A).
---------------------------------------------------------------------------
The Department proposes to clarify the implementation specification
for emergency mode operation planning, redesignated as proposed 45 CFR
164.308(a)(13)(ii)(E), by clarifying that procedures must be written.
We also propose to redesignate the implementation specification for
testing and revision procedures as paragraph (a)(13)(ii)(F) and to
clarify that procedures for testing and revising of the required
contingency plans must be established in writing. We propose to require
a regulated entity to review and implement its procedures for testing
contingency plans at least once every 12 months, to document the
results of such tests, and to modify those plans as reasonable and
appropriate based on the results of those tests.
p. Section 164.308(a)(14)--Standard: Compliance Audit
The final standard we propose under 45 CFR 164.308(a) is a new
standard for compliance audits at proposed 45 CFR 164.308(a)(14). For
this proposed standard, the Department proposes to require regulated
entities to perform and document an audit of their compliance with each
standard and implementation specification of the Security Rule at least
once every 12 months.
While the Security Rule does not currently require regulated
entities to conduct internal or third-party compliance audits, such
activities are important components of a robust cybersecurity program.
The Government Accountability Office has published guidance on
conducting cybersecurity performance audits for Federal agencies.\612\
Audits are typically conducted independently from information security
management, and the function generally reports to the governing body of
the regulated entity. This independence can provide an objective view
of the regulated entity's policies and practices. According to the
Institute of Internal Auditors, an internal audit provides
``[i]ndependent and objective assurance and advice on all matters
related to the achievement of objectives.'' \613\ An internal audit may
be conducted by a business associate of a covered entity or a
subcontractor of a business associate. These activities provide
regulated entities with confidence in the effectiveness of their risk
management plan. Thus, we believe that this proposal would aid a
regulated entity in ensuring compliance with the Security Rule, and
ultimately, protecting ePHI. We do not propose to specify whether the
compliance audit should be performed by the regulated entity or an
external party.\614\
---------------------------------------------------------------------------
\612\ See ``Cybersecurity Program Audit Guide,'' GAO-23-104705,
U.S. Government Accountability Office, p. 1 (Sept. 28, 2023),
https://www.gao.gov/products/gao-23-104705; see also ``Security and
Privacy Controls for Information Systems and Organizations,'' supra
note 600.
\613\ See ``The IIA's Three Lines Model: An update of the Three
Lines of Defense,'' The Institute of Internal Auditors, p. 4 (Sept.
9, 2020), https://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdf.
\614\ We believe that health plans that are subject to HIPAA and
to the Employee Retirement Income Security Act of 1974 could comply
with the proposed compliance audit requirement and follow the
Employee Benefits Security Administration's Cybersecurity Program
Best Practices, which specifies that all such plans have a reliable
annual third party audit of security controls. ``Cybersecurity
Program Best Practices,'' Employee Benefits Security Administration,
U.S. Department of Labor, p. 1, 2 (Apr. 2021), https://www.dol.gov/sites/dolgov/files/ebsa/pdf_files/best-practices.pdf;
``Cybersecurity Guidance Update,'' Employee Benefits Security
Administration, U.S. Department of Labor (Sept. 6, 2024), https://www.dol.gov/agencies/ebsa/key-topics/retirement-benefits/cybersecurity/compliance-assistance-release-2024-01.
---------------------------------------------------------------------------
[[Page 956]]
q. Section 164.308(b)(1) and (2)--Standard: Business Associate
Contracts and Other Arrangements
Vendor management and identification of risks in a supply chain are
essential to controlling the introduction of new threats and risks to a
regulated entity.\615\ NIST guidance explains that regulated entities,
are permitted to include more stringent cybersecurity measures in
business associate agreements than those required by the Security
Rule.\616\ Such requirements would need to be agreed upon by both
parties to the business associate agreement.\617\ The guidance also
recommends establishing a process for measuring contract performance
and terminating the contract if security requirements are not being
met. Important considerations include: Is there a process for reporting
security incidents related to the agreement? Are additional assurances
of protections for ePHI from the business associate necessary? If so,
where would such additional assurances be documented (e.g., in the
business associate agreement, service-level agreement, or other
documentation) and how would they be met (e.g., providing documentation
of implemented safeguards, audits, certifications)?
---------------------------------------------------------------------------
\615\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461.
\616\ Id. at 54.
\617\ Id.
---------------------------------------------------------------------------
The Security Rule requires a regulated entity to protect the
confidentiality, integrity, and availability of all ePHI that it
creates, receives, maintains, or transmits.\618\ It also requires a
regulated entity to obtain written satisfactory assurances that its
business associate will appropriately safeguard ePHI before allowing
the business associate to create, receive, maintain, or transmit ePHI
on its behalf.\619\ However, the Security Rule does not require a
regulated entity to verify that entities that create, receive,
maintain, or transmit ePHI on its behalf are in fact taking the
necessary steps to protect such ePHI. The lack of such a requirement
may leave a gap in protections from risks to ePHI related to regulated
entities' vendors and supply chains. Accordingly, the Department
proposes several modifications to the Security Rule to provide greater
assurance that business associates and their subcontractors are
protecting ePHI because a subcontractor to a business associate is also
a business associate. The Department proposes to redesignate 45 CFR
164.308(b)(1) and (2) as proposed 45 CFR 164.308(b)(1)(i) and (ii),
respectively. Additionally, we propose to make a technical correction
to the standard for business associate contracts and other arrangements
for organizational clarity, separating proposed paragraph (b)(1)(i)
into paragraphs (b)(1)(i)(A) and (B). We believe this is a non-
substantive change that would have no effects on any regulatory,
recordkeeping, or reporting requirement, nor would it change the
Department's interpretation of any regulation. We also propose to
modify both to require a regulated entity to verify that the business
associate has deployed the technical safeguards required by 45 CFR
164.312 \620\ in addition to obtaining satisfactory assurances that its
business associate would comply with the Security Rule.\621\ To assist
regulated entities in complying with the new standard, we propose to
redesignate the implementation specifications at 45 CFR 164.308(b)(3)
as 45 CFR 164.308(b)(2) and propose to add an implementation
specification for written verification at proposed 45 CFR
164.308(b)(2)(ii) that would require the regulated entity to obtain
written verification from the business associate that the business
associate has deployed the required technical safeguards.\622\ The
Department proposes to require that the regulated entity obtain this
written verification documenting the business associate's deployment of
the required technical safeguards at least once every 12 months.\623\
Additionally, we propose that the verification include a written
analysis of the business associate's relevant electronic information
systems.\624\ The written analysis would be required to be performed by
a person with appropriate knowledge of and experience with generally
accepted cybersecurity principles and methods for ensuring the
confidentiality, integrity, and availability of ePHI to verify the
business associate's compliance with each standard and implementation
specification in 45 CFR 164.312.\625\ We also propose to require that
the written verification be accompanied by a written certification by a
person who has the authority to act on behalf of the business associate
that the analysis has been performed and is accurate.\626\ The proposal
would permit the parties to determine the appropriate person to perform
the analysis and how that person is engaged or compensated. This person
may be a member of the covered entity's or business associate's
workforce or an external party.
---------------------------------------------------------------------------
\618\ See 45 CFR 164.306(a)(1).
\619\ See 45 CFR 164.308(b).
\620\ See proposed 45 CFR 164.308(b)(1)(i) and (ii).
\621\ Id.
\622\ See proposed 45 CFR 164.308(b)(2)(ii).
\623\ Id.
\624\ Proposed 45 CFR 164.308(b)(2)(ii)(A).
\625\ Id.
\626\ Proposed 45 CFR 164.308(b)(2)(ii)(B).
---------------------------------------------------------------------------
This proposed new requirement that a regulated entity obtain
written verification from its business associates that they have
deployed technical safeguards combined with the existing requirement to
obtain written satisfactory assurances that they safeguard ePHI, aligns
with the Department's essential CPG for Vendor/Supplier Cybersecurity
Requirements.\627\ This CPG calls for regulated entities to identify,
assess, and mitigate risks to ePHI used by or disclosed to business
associates.\628\
---------------------------------------------------------------------------
\627\ ``Cybersecurity Performance Goals,'' supra note 18; see
also proposed 45 CFR 164.308(b)(2)(i).
\628\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
r. Section 164.308(b)(3)--Standard: Delegation To Business Associate
Based on the OCR's investigations and enforcement experience, we
believe that some regulated entities are not aware that they retain
compliance responsibility for implementing requirements of the Security
Rule, even when they have delegated the functions of designated
security official to a business associate. Therefore, the Department
proposes a new standard for delegation to a business associate at
proposed 45 CFR 164.308(b)(3). The proposed standard would clarify that
a regulated entity may permit a business associate to serve as its
designated security official.\629\ However, a regulated entity that
delegates actions, activities, or assessments required by the Security
Rule to a business associate remains liable for compliance with all the
applicable provisions of the Security Rule.\630\
---------------------------------------------------------------------------
\629\ Proposed 45 CFR 164.308(b)(3)(i).
\630\ Proposed 45 CFR 164.308(b)(3)(ii).
---------------------------------------------------------------------------
4. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular. For any
proposed timeframe that a commenter believes is not appropriate, we
request comment and explanation on a more appropriate timeframe.
[[Page 957]]
a. Whether the Department should require a regulated entity to
implement any additional administrative safeguards. If so, please
explain.
b. Whether the Department should not require a regulated entity to
implement any of the existing or proposed standards for implementation
specifications. If so, please explain.
c. Whether there are additional implementation specifications that
should be adopted for any of the standards for administrative
safeguards.
d. Whether the Department should provide any exceptions to the
administrative safeguards or related implementation specifications. If
so, please explain when and why any exceptions should apply.
e. Whether once every 12 months is the appropriate frequency
between reviews of policies, procedures, and other activities required
by the other standards for administrative safeguards.
f. Whether there are any special considerations for business
associates and business associate agreements that the Department should
be aware of with respect to administrative safeguards.
g. Whether there are any requirements for business associates and
business associate agreements that the Department should include in
administrative safeguards that it did not propose.
h. Whether the Department should require covered entities to report
to their business associates (or business associates to their
subcontractors) the activation of the covered entities' (or business
associates') contingency plans. If so, please explain the appropriate
circumstances of and the appropriate amount of time for such
notification.
i. Whether once every 12 months is an appropriate length of time in
which a covered entity must verify and document that a business
associate has deployed technical safeguards pursuant to the
requirements.
j. Whether the Department should require covered entities to obtain
satisfactory assurances and verify that a business associate has
implemented physical or other safeguards in addition to deploying
technical safeguards before permitting it to create, receive, maintain,
or transmit ePHI on its behalf.
k. Whether on an ongoing basis, but at least once every 12 months
and when there is a change to a regulated entity's environment or
operations that affects ePHI, is the appropriate frequency for updating
the technology asset inventory and network map?
l. Whether on an ongoing basis, but at least once every 12 months
and when there is a change to the regulated entity's environment or
operations that affects ePHI, is the appropriate frequency for
performing a risk analysis?
m. Whether there are additional events for which the Department
should require a regulated entity to update its risk analysis. If so,
please explain.
n. Whether the Department should include or exclude any specific
circumstances from its explanation of environmental or operational
changes when determining whether review or update of the written
inventory of technology assets and network map or review of the risk
analysis written assessment is warranted.
o. Whether the proposed requirement in the standard for evaluation,
to perform a written technical and nontechnical evaluation within a
reasonable period of time before making a change in the regulated
entity's environment or operations pursuant to the requirements, is
sufficiently clear. If not, how should the Department clarify it? For
example, should the Department require a specific amount of time, and
if so, what length of time?
p. Whether at least once every 12 months is the appropriate
frequency for reviewing and updating written policies and procedures
for patch management, sanctions policies and procedures information
system activity review, workforce security, and information access
management.
q. Whether as reasonable and appropriate in response to changes in
the risk analysis, but at least once every 12 months, is the
appropriate frequency for reviews of a regulated entity's written risk
management plan.
r. Whether the proposed frequency for security awareness training
is appropriate.
s. Whether the proposed substance of the security awareness
training is appropriate, and any recommendations for additional
required content.
t. Whether the proposed timelines for applying patches, updates,
and upgrades are appropriate.
u. Whether the Department should set a time limit for applying
patches, updates, and upgrades to configurations of relevant electronic
information systems to address moderate and low risks. If so, please
explain and provide a recommendation.
v. Whether the amount of time regulated entities currently retain
records of information system activity varies by the type of record,
and for how long such records are retained.
w. Whether the Department should specify the length of time for
which records of information system activity should be retained. If so,
please explain.
x. Whether the Department should require that a regulated entity
notify other regulated entities of the termination of a workforce
member's access to ePHI in less than 24 hours after the workforce
member's termination. If so, please explain what would be an
appropriate period of time (e.g., three business hours, 12 hours).
y. Whether at least once every 12 months is the appropriate
frequency for testing security incident response plans, documenting the
results, and revising such plans.
z. Whether it is reasonable and appropriate to require that
regulated entities restore loss of critical relevant electronic
information systems and data in 72 hours or less.
aa. Whether the Department should require a regulated entity to
restore all of its relevant electronic information systems and data
within 72 hours?
bb. Whether the Department should require some regulated entities
to restore their relevant electronic information systems and data in
less than 72 hours? If so, please explain.
cc. Whether at least once every 12 months is the appropriate
frequency for the testing of contingency plans?
dd. Whether annual auditing of a regulated entity's compliance with
the Security Rule is appropriate.
ee. Whether the Department should specify the level of detail or
standard required for the annual compliance audit. If so, please
explain.
ff. Whether the Department should require a regulated entity to
obtain written verification of their business associates'
implementation of the administrative and physical safeguards that are
required by the Security Rule, in addition to the proposed requirement
to obtain verification of implementation of the technical safeguards.
If so, please explain.
gg. Whether there are other requirements for which the Department
should require that the person performing them have a specific level or
type of expertise. If so, please explain.
E. Section 164.310--Physical Safeguards
1. Current Provisions
A person with physical access to electronic media or a regulated
entity's electronic information systems that create, receive, maintain,
or transmit or that otherwise affect the confidentiality, integrity,
and availability of ePHI might have the opportunity to change the
configurations of its relevant electronic information systems, install
malicious software or otherwise adversely affect technology assets in
its relevant
[[Page 958]]
electronic information systems, change information, or access ePHI or
other sensitive information.\631\ Any of these actions has the
potential to adversely affect the confidentiality, integrity, or
availability of ePHI, which means that physical safeguards for
electronic media and a regulated entity's relevant electronic
information systems are critical to protecting the security of ePHI.
Thus, the physical safeguards standards address the essential
requirements for regulated entities to apply to limit physical access
to their relevant electronic information systems to only authorized
workforce members. As discussed above, ePHI is increasingly transmitted
using interconnected systems that rely on cloud computing. The shift to
a cloud-based infrastructure may increase regulated entities' reliance
on business associates to maintain and access ePHI stored in the
cloud.\632\ Additionally, the shift to cloud computing enables
regulated entities' workforce members to access ePHI and relevant
electronic information systems from a greater number of locations.
Accordingly, regulated entities must appropriately expand and/or ensure
that applied physical safeguards take into account these new
arrangements.
---------------------------------------------------------------------------
\631\ ``Considerations for Securing Electronic Media and
Devices,'' Office for Civil Rights, U.S. Department of Health and
Human Services, p. 1 (Aug. 2018), https://www.hhs.gov/sites/default/files/cybersecurity-newsletter-august-2018-device-and-media-controls.pdf.
\632\ See, e.g., Sonali Sachdeva, et al., ``Unraveling the role
of cloud computing in health care system and biomedical sciences,''
Heliyon (Apr. 2, 2024) (``These days numerous commercial merchants
are intermingling with hospitals as well as healthcare providers to
establish healthcare-based cloud computing networks.''), https://www-ncbi-nlm-nih-gov.hhsnih.idm.oclc.org/pmc/articles/PMC11004887/;
see also id. (``[. . .] Microsoft, Google and Amazon have instantly
realized that the majority of hospitals will not continue working
with servers that are privately owned as well as controlled.'');
``Increase in health-care cyberattacks affecting patients with
cancer,'' supra note 180 (In 2021, an attack against oncology
services targeted data stored in cloud-based systems and affected
patients in several States.).
---------------------------------------------------------------------------
Section 164.310 includes the four standards with which a regulated
entity must comply to physically secure relevant electronic information
systems and the premises where they are located. These standards
require regulated entities to implement physical safeguards for
facility access controls, workstation use, workstation security, and
device and media controls in a manner that conforms with 45 CFR
164.306(c), the general compliance provision for the security
standards.
As discussed above in greater detail, physical safeguards encompass
the physical measures, and related policies and procedures, to protect
relevant electronic information systems and related buildings and
equipment from natural and environmental hazards, and unauthorized
intrusion.\633\ The standard for facility access controls applies to
protect the physical premises, while the standards for workstation use,
workstation security, and device and media controls are aimed at
protecting the electronic information systems and electronic media that
create, receive, maintain, or transmit ePHI or that otherwise affect
its confidentiality, integrity, and availability.
---------------------------------------------------------------------------
\633\ See 45 CFR 164.304 (definition of ``Physical
safeguards'').
---------------------------------------------------------------------------
The standard for facility access controls at 45 CFR 164.310(a)(1)
requires a regulated entity to implement policies and procedures that
limit physical access to electronic information systems and facilities
that contain those systems. Section 164.310(a)(1) also requires a
regulated entity to ensure its policies and procedures allow persons
who are properly authorized to access its facilities.
Under 45 CFR 164.310(a)(2), a regulated entity must implement the
standard for facility access controls in accordance with four
implementation specifications. The implementation specification for
contingency operations addresses the establishment (and implementation
as needed) of procedures that allow for facility access in support of
the restoration of lost data under a disaster recovery plan and
emergency mode operations.\634\ Section 164.310(a)(2)(ii) contains the
specification for a facility security plan and addresses the
implementation of policies and procedures to safeguard facilities and
equipment in such facilities from unauthorized physical access,
tampering, and theft. The implementation of procedures for role-based
access control, including for visitors and for access to software
programs for testing and revision is addressed in 45 CFR
164.310(a)(2)(iii), while 45 CFR 164.310(a)(2)(iv) addresses the
implementation of policies and procedures for the documentation of
repairs and modifications to physical security components of a
facility, such as hardware, walls, doors, and locks.
---------------------------------------------------------------------------
\634\ 45 CFR 164.310(a)(2)(i).
---------------------------------------------------------------------------
Section 164.310(b) requires a regulated entity to implement
policies and procedures specifying proper workstation functions, the
manner in which those functions are to be performed, and the physical
attributes of the environment for where specific workstations or
classes of workstation used for accessing ePHI.\635\ This standard is
not accompanied by standalone implementation specifications, compared
to the standards for facility access controls at 45 CFR 164.310(a) and
device and media controls at 45 CFR 164.310(d). Section 164.310(c), the
standard for workstation security, also is not accompanied by
standalone addressable or required implementation specifications, but
it does require a regulated entity to implement physical safeguards
that restrict all workstations, such as a laptop or desktop computer or
any other device that performs similar functions, that access ePHI to
authorized users.\636\
---------------------------------------------------------------------------
\635\ 45 CFR 164.310(b).
\636\ 45 CFR 164.310(c).
---------------------------------------------------------------------------
Device and media controls can help regulated entities respond to
and recover from security incidents and breaches.\637\ Proper
understanding of and implementation of such controls may enable
regulated entities to quickly determine which devices and electronic
media may be implicated in an actual or suspected security incident, or
breach, and respond accordingly.\638\ For example, if cybercriminals
gained access to an organization's network by exploiting a
vulnerability present in a particular electronic device, a robust and
accurate inventory and tracking process could identify how many devices
are affected and where they are located. With this information, a
regulated entity should be able to make more effective use of its
resources and respond more effectively to an actual or suspected
security incident or breach involving such devices. Thus, it is
important for regulated entities to implement the device and media
controls required under 45 CFR 164.310(d). Accordingly, the standard
for device and media controls at 45 CFR 164.310(d), requires a
regulated entity to implement policies and procedures to govern how
hardware and electronic media containing ePHI are received or removed
from a facility and within a facility. Section 164.310(d)(2) includes
two required and two addressable implementation specifications.
Paragraphs (d)(2)(i) and (ii) on disposal and media re-use,
respectively require a regulated entity to implement policies and
procedures that address the final disposition of ePHI and the hardware
or electronic media on which it is stored, and the removal of ePHI
before the electronic media is re-used. Section 164.308(d)(2)(iii)
addresses the
[[Page 959]]
maintenance of a record of the movement of hardware and electronic
media and any person responsible for such hardware or electronic media,
while the provision on data backup and storage at 45 CFR
164.310(d)(2)(iv) addresses the creation of a retrievable, exact copy
of ePHI before moving the equipment.
---------------------------------------------------------------------------
\637\ ``Considerations for Securing Electronic Media and
Devices,'' supra note 631, p. 2.
\638\ Id.
---------------------------------------------------------------------------
2. Issues To Address
The Department has concerns regarding the effectiveness of the
language used in the physical safeguards in 45 CFR 164.310 for the same
reasons discussed in the context of 45 CFR 164.306 and 164.316. For
example, while 45 CFR 164.310 contemplates that a regulated entity must
implement the standards and implementation specifications required
under 45 CFR 164.310 in accordance with the general documentation and
maintenance requirements found in 45 CFR 164.306 and 164.316, at least
one court has stated that compliance obligations are limited to the
plain words of regulatory text and that a requirement to ``implement''
does not mean that a requirement must be in place throughout the
regulated entity's enterprise.\639\ Additionally, the standards for
facility access controls, workstation use, and device and media
controls all require a regulated entity to implement policies and
procedures, while the standard for workstation security requires
regulated entities to implement physical safeguards. The differences in
regulatory text among these provisions could be interpreted to mean
that a regulated entity's obligations differ depending on whether a
provision requires it to implement only policies and procedures or
whether the provision requires the implementation of something more.
This may confuse regulated entities and lead some to believe that less
comprehensive protection is needed for ePHI subject only to policies
and procedures.
---------------------------------------------------------------------------
\639\ See University of Texas M.D. Anderson Cancer Center, supra
note 258, p. 479.
---------------------------------------------------------------------------
The Department believes that the current Security Rule provides a
clear path for regulated entities to protect the confidentiality,
integrity, and availability of ePHI. However, as discussed above, we
also believe recent caselaw has created confusion about the steps
regulated entities must take to adequately protect the confidentiality,
integrity, and availability of ePHI, as required by the statute.
Further, the conditions highlighted by caselaw may also cause regulated
entities to misinterpret the regulatory text that connects the current
maintenance requirement at 45 CFR 164.306(e), the documentation
requirement at 45 CFR 164.316, and the requirement to implement
physical safeguards. For example, regulated entities may be confused
about how 45 CFR 164.316 requires a regulated entity to document the
policies and procedures for specific physical safeguard in 45 CFR
164.310 (or across any other safeguard). In this case, the regulated
entity also might not apply the implementation specifications to
retain, make available, and review documentation of how it has
operationalized the physical safeguard. Failing to connect these
provisions would lead to inadequate protection of ePHI and/or an
inability to demonstrate compliance with the Security Rule.
Our experience enforcing the Security Rule provides examples of the
types of breaches that can occur because of absent or insufficient
physical safeguards:
An investigation of a large health system indicated
potential failures to implement policies and procedures and facility
access controls to limit physical access to the electronic information
systems housed within a large data support center. While the health
system did have video surveillance, the investigation found indications
that laptops were stored in an interior room that was unlocked and the
facility did not have an alarm system.\640\
---------------------------------------------------------------------------
\640\ Resolution Agreement, ``Advocate Health Care Network
Medical Group,'' Office for Civil Rights, U.S. Department of Health
and Human Services (July 8, 2016).
---------------------------------------------------------------------------
A large university hospital experienced a breach of
unsecured PHI when it lost an unencrypted flash drive and unencrypted
laptop. The Department's investigation found that the covered entity
may have failed to use device and media controls, which might have
prevented the loss of these devices.\641\
---------------------------------------------------------------------------
\641\ Resolution Agreement, ``University of Rochester Medical
Center,'' Office for Civil Rights, U.S. Department of Health and
Human Services (Oct. 30, 2019) (describing a violation of the
standard for device and media controls).
---------------------------------------------------------------------------
Given the increased portability of devices, media, workstations,
and information systems, such components may often be located outside
of a regulated entity's physical location. For example, OCR has
investigated several incidents involving portable electronic media and
mobile workstations that were removed from the regulated entity's
physical environment and subsequently lost. As a result, the Department
believes that we should more broadly construe the physical environment
where ePHI is stored and accessed because it is essential that
regulated entities have policies and procedures in place to address the
portability of components of their information systems, as well as the
ability of workforce members to access such information systems offsite
using portable workstations.
Additionally, the standard for device and media controls at 45 CFR
164.310(d)(1) applies only to devices and media, rather than all
technology assets that may be components of a regulated entity's
relevant electronic information systems. The Department is concerned
that a regulated entity may have other types of technology assets that
may either create, receive, maintain, or transmit ePHI or otherwise
affect its confidentiality, integrity, or availability and that can be
removed from, brought to, or moved within its facilities. The
confidentiality, integrity, or availability of the regulated entity's
ePHI could be negatively affected in the absence of written policies
and procedures governing the movement of such technology assets.
Finally, we believe that it is important to address several issues
in the standards and implementation specifications for the physical
safeguards that are also addressed in other proposals: addressing the
Department's expectations regarding implementation specifications;
\642\ memorializing policies and procedures in writing; documenting the
implementation of the aforementioned policies and procedures; reviewing
such policies and procedures on a regular cadence; modifying such
policies and procedures when reasonable and appropriate; \643\ and
clarifying the scope of the electronic information systems and their
components that regulated entities are expected to consider when
establishing their policies and procedures.\644\
---------------------------------------------------------------------------
\642\ See discussion of 45 CFR 164.306.
\643\ See University of Texas M.D. Anderson Cancer Center, supra
note 258.
\644\ See 45 CFR 164.304 (proposed definitions of ``Relevant
electronic information systems'' and ``Technology assets'').
---------------------------------------------------------------------------
3. Proposals
The Department proposes to retain the four standards that comprise
the Security Rule's physical safeguards required by 45 CFR 164.306 and
codified in 45 CFR 164.310. However, we propose several modifications
to 45 CFR 164.310 to address the issues identified above.
a. Section 164.310--Physical Safeguards
The Department proposes to expand the introductory language at 45
CFR
[[Page 960]]
164.310 to clarify that the Security Rule requires that physical
safeguards be applied to all ePHI in the possession of the regulated
entity, that is, throughout the regulated entity's facilities. The
Department also proposes to expand this section to expressly require a
regulated entity to implement physical safeguards in accordance with
not only 45 CFR 164.306, but also 45 CFR 164.316 to connect the
overarching documentation requirements.
Consistent with the proposals to revise the general requirements in
45 CFR 164.306(c) and (d), the Department proposes to remove any
distinction between addressable and required implementation
specifications in this section such that all specifications would be
required. Also consistent with changes proposed elsewhere in this NPRM,
the Department proposes to modify all four physical safeguard standards
to require that the requisite policies and procedures be in writing
\645\ and implemented throughout the enterprise.\646\ Under this
proposal, a regulated entity that could not produce a written policy
describing how it will implement a required physical safeguard and
demonstrate that the safeguard is in effect and operational throughout
the enterprise would not be in compliance with the standard. Consistent
with our proposals to require that regulated entities maintain their
administrative safeguards, the Department also proposes to require a
regulated entity to maintain its security measures by reviewing and
testing the required security measures at least once every 12 months,
and by modifying the same as reasonable and appropriate. Additionally,
we propose to modify certain standards and implementation
specifications to ensure that regulated entities understand their
obligations to ensure the confidentiality, integrity, and availability
of ePHI by implementing physical safeguards to protect their relevant
electronic information systems and/or the technology assets in their
relevant electronic information systems.
---------------------------------------------------------------------------
\645\ See discussion of proposals to revise 45 CFR 164.316.
\646\ See 45 CFR 164.304 (proposed definition of ``Implement'').
---------------------------------------------------------------------------
b. Section 164.310(a)(1)--Standard: Facility Access Controls
The Department proposes to modify the standard for facility access
controls at 45 CFR 164.310(a)(1) to clarify that the policies and
procedures required by this standard must be in writing and address
physical access to all of a regulated entity's relevant electronic
information systems and the facility or facilities in which these
systems are housed and to add a paragraph to clarify the organization
of the regulatory text. The Department also proposes to modify the
implementation specifications associated with the standard for facility
access controls. Specifically, we propose to modify the implementation
specifications for contingency operations, facility security plan, and
access control and validation procedures at 45 CFR 164.310(a)(2)(i)
through (iii) to clarify that we expect a regulated entity to not only
establish and implement policies and procedures, but also that we
expect them to be in writing.
The Department's proposal would also require that the procedures
for contingency operations proposed at 45 CFR 164.310(a)(2)(i) support
the regulated entity's contingency plan, instead of the current
requirement specifying that the procedures support the restoration of
lost data under the disaster recovery plan and emergency mode
operations plan in the event of an emergency.\647\ This proposal would
align the implementation specification for contingency operations with
the standard for contingency planning at proposed 45 CFR
164.308(a)(13)(i) by specifically ensuring that the written policies
and procedures support the required contingency plan. It also would
avoid duplicating the implementation specification for disaster
recovery planning at proposed 45 CFR 164.308(a)(13)(ii)(D), which would
require a regulated entity to address the restoration of lost data and
systems in the disaster recovery plan component of its contingency
plan. We propose to modify 45 CFR 164.310(a)(2)(ii) to clarify that the
written policies and procedures that constitute the facility security
plan must apply to all of the regulated entity's facilities and
equipment contained within those facilities. The Department proposes to
retitle the implementation specification for access control and
validation procedures at 45 CFR 164.310(a)(2)(iii) as ``Access
management and validation procedures'' and to require regulated
entities to establish and implement written procedures to both
authorize and manage a person's role-based access to facilities.
---------------------------------------------------------------------------
\647\ See proposed 45 CFR 164.308(a)(13).
---------------------------------------------------------------------------
In the implementation specification for maintenance records, the
Department proposes at 45 CFR 164.310(a)(2)(iv), to change the
provision heading to ``Physical maintenance records'' and to add
security cameras to the list of examples of physical security
components about which a regulated entity is required to implement
written policies and procedures to document repairs and modifications.
Both proposals are consistent with and recognize the evolution of the
role that technology plays in managing and granting physical access to
facilities.
Consistent with our proposals to add maintenance requirements where
we believe it is necessary for regulated entities to review, test, and
modify their security measures on a particular cadence, we also propose
to add an implementation specification for maintenance at proposed 45
CFR 164.310(a)(2)(v). The maintenance provision would require that, for
each facility, a regulated entity review and test its written policies
and procedures at least once every 12 months, and to modify those
policies and procedures as reasonable and appropriate based on that
review.
c. Section 164.310(b)(1)--Standard: Workstation Use and Section
164.310(c)--Standard: Workstation Security
Further, in the standards for workstation use and workstation
security at 45 CFR 164.310(b) (redesignated as proposed 45 CFR
164.310(b)(1) and (c), respectively), the Department proposes several
changes that would recognize the increasingly mobile nature of ePHI and
workstations that connect to the information systems of regulated
entities. The purpose of these proposals is to ensure that regulated
entities properly consider physical safeguards for all workstations,
including those that are mobile, and not only those that are located in
regulated entities' facilities. The Department also proposes to modify
both standards to clarify the organization of the regulatory text. The
Department proposes to modify the standard for workstation use to
clarify that policies and procedures established by a regulated entity
to govern the use of workstations be in writing and address all
workstations that access ePHI or the regulated entity's relevant
electronic information systems. These proposed changes are consistent
with the Department's longstanding expectations and other proposals in
this NPRM described above. In 45 CFR 164.310(b)(2)(i)(C), the
Department proposes to require a regulated entity to establish and
implement written policies and procedures that, among other things,
specify the physical attributes of workstation surroundings, including
the removal of workstations from a facility and the movement of
workstations within and outside of a facility. This proposal is
consistent with
[[Page 961]]
the proposed revision to the definition of ``workstation'' discussed
above. Additionally, we propose to add an implementation specification
for maintenance at proposed 45 CFR 164.310(b)(2)(ii) to require that a
regulated entity review and test its written policies and procedures at
least once every 12 months, and to modify those policies and procedures
as reasonable and appropriate based on that review.
Relatedly, the Department proposes to modify the standard for
workstation security at 45 CFR 164.310(c) to require a regulated entity
to implement physical safeguards for workstations that access ePHI or
relevant electronic information systems to comply with its written
policies and procedures for workstation use. This proposal would also
make clear that such physical safeguards must be modified in response
to any modifications to the written policies and procedures for
workstation use. As part of their policies and procedures for
workstation security, the Department encourages regulated entities to
consider, among other things, whether there are workstations located in
public areas or other areas that are more vulnerable to theft,
unauthorized use, or unauthorized viewing; whether such devices should
be relocated; the physical security controls for workstations that are
in use (e.g., cable locks, privacy screens, secured rooms, cameras) and
whether they are easy to use; and whether there are additional physical
security controls that could reasonably be put into place.\648\
Additionally, consistent with the Department's proposal to require that
a regulated entity provide role-based security awareness training on
its Security Rule policies and procedures,\649\ the Department expects
that such training would address the physical safeguards it has
implemented, particularly those policies and procedures for mobile
devices that are used to create, receive, maintain, or transmit ePHI or
that otherwise affect the confidentiality, integrity, or availability
of ePHI.
---------------------------------------------------------------------------
\648\ See ``Workstation Security: Don't Forget About Physical
Security,'' Office for Civil Rights, U.S. Department of Health and
Human Services, p. 2 (May 2018), https://www.hhs.gov/sites/default/files/cybersecurity-newsletter-may-2018-workstation-security.pdf.
\649\ See proposed 45 CFR 164.308(a)(11)(ii)(A)(1).
---------------------------------------------------------------------------
d. Section 164.310(d)(1)--Standard: Technology Asset Controls
The Department proposes to modify the standard at 45 CFR
164.310(d)(1) by changing the heading to ``Technology asset controls''
from ``Device and media controls,'' and replacing ``hardware and
electronic media'' in 45 CFR 164.310(d)(1) and (2) with ``technology
assets.'' We believe that this modification would more accurately
capture the various categories of components of a regulated entity's
relevant electronic information systems that may be received in,
removed from, or moved within a facility and that also affect the
confidentiality, integrity, or availability of ePHI. Thus, we believe
that this modification would provide regulated entities with a clearer
understanding of their compliance obligations with respect to the
physical safeguards that should be implemented to protect ePHI when
technology assets are received by, removed from, or moved within a
facility. While we are not proposing other significant changes to 45
CFR 164.310(d)(1) at this time, we remind regulated entities to
consider the appropriateness of the policies and procedures they have
implemented with respect to the movement of technology assets that
maintain ePHI into and out of their facilities and the movement of
these items within their facilities. The processes a regulated entity
chooses to implement to govern the movement of technology assets may
vary based on the type of technology asset.\650\ For example, once
installed, a server or desktop computer may not need to be moved for
the entirety of its lifecycle within the regulated entity, while
portable electronic devices and media, such as smartphones, tablets,
and USB flash drives are designed to be mobile and may move frequently
into, out of, and within a regulated entity's facilities.\651\ Thus,
the regulated entity's policies and procedures must account for these
differences.\652\ Further, we note that the proposed definition of
workstation includes mobile devices. Mobile devices that serve as
workstations are subject to the requirements in this paragraph and
those in paragraphs (b) and (c).
---------------------------------------------------------------------------
\650\ ``Considerations for Securing Electronic Media and
Devices,'' supra note 631, p. 1.
\651\ Id.
\652\ See id. for a list of questions that regulated entities
should consider when developing their policies and procedures
regarding device and media controls.
---------------------------------------------------------------------------
The Department also proposes to modify the standard at 45 CFR
164.310(d)(1) to clarify the organization of regulatory text and to
clarify its longstanding expectations that policies and procedures must
be in writing and to replace ``contain'' with ``maintain,'' consistent
with terminology used throughout the HIPAA Rules. The Department
believes that having written policies for the disposal of ePHI and the
technology assets on which it is stored and for the removal of ePHI
from electronic media such that the ePHI cannot be recovered continues
to be important to ensuring the physical safety of ePHI. Improper
disposal of technology assets puts the ePHI stored in or on such assets
at risk for a potential breach, and as discussed elsewhere, data
breaches can result in substantial costs to regulated entities and the
individuals affected by the breach. We also propose in the related
implementation specifications at 45 CFR 164.310(d)(2)(i) and (ii) to
require that written policies and procedures for disposal of ePHI and
sanitization of electronic media be tied to current standards for
sanitizing electronic media before the media are made available for re-
use.\653\ For example, photocopiers today are often connected to the
same network as workstations and generally store the information,
including ePHI, transmitted to them. This capability is a significant
change from photocopier capabilities that existed when the Security
Rule was first issued in 2003. Under this proposal, a regulated entity
would be required to include in its written policies and procedures for
disposing of ePHI, and the technology assets on which it is maintained,
policies and procedures addressing ePHI maintained on photocopiers,
consistent with the current standards for disposing and removing ePHI
from electronic media.\654\
---------------------------------------------------------------------------
\653\ See Richard Kissel, et al., ``Guidelines for Media
Sanitization,'' NIST Special Publication 800-88, Revision 1,
National Institute of Standards and Technology, U.S. Department of
Commerce (Dec. 2014), https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final; see also ``Proper Disposal of Electronic
Devices,'' Cybersecurity & Infrastructure Security Agency, U.S.
Department of Homeland Security (Feb. 1, 2021), https://www.cisa.gov/news-events/news/proper-disposal-electronic-devices.
\654\ See ``Guidelines for Media Sanitization,'' supra note 653;
see also ``Proper Disposal of Electronic Devices,'' supra note 653.
---------------------------------------------------------------------------
We have previously explained in guidance that a regulated entity
should consider all of the following as part of its risk analysis:
Disposal of hardware and software, and the documentation
of such disposal.
Destruction of ePHI in such a manner that it cannot be
recreated.
Secure removal of ePHI that was previously stored on
hardware or electronic media such that it cannot be accessed and
reused.
The identification of all removable media and their use
(e.g., CDs/DVDs, USB flash drives).
[[Page 962]]
The removal of all ePHI from reusable media before the
media are reused.\655\
---------------------------------------------------------------------------
\655\ ``Guidance on Disposing of Electronic Devices and Media,''
Office for Civil Rights, U.S. Department of Health and Human
Services, p. 1 (July 2018), https://www.hhs.gov/sites/default/files/cybersecurity-newsletter-july-2018-Disposal.pdf.
---------------------------------------------------------------------------
Our guidance describes these considerations in greater detail. For
example, regulated entities should consider how to address the
replacement of technology assets, including devices and media.\656\
Technology assets that need to be replaced should be decommissioned,
meaning that they are taken out of service before the final disposition
of such assets.\657\ Steps a regulated entity should consider as part
of its decommissioning process include: ensuring technology assets are
securely erased and then either securely destroyed or recycled;
ensuring that the regulated entity's technology asset inventory is
updated to accurately reflect the status of decommissioned technology
assets or technology assets slated to be decommissioned; and ensuring
that privacy is protected through proper migration to another
electronic information system or total destruction of the ePHI.\658\
---------------------------------------------------------------------------
\656\ Id. at 2.
\657\ Id.
\658\ Id.
---------------------------------------------------------------------------
The Department proposes to remove the implementation specifications
for accountability and data backup and storage at 45 CFR
164.310(d)(2)(iii) and (iv). We believe that the accountability
provisions would be subsumed and replaced by the proposed standard for
technology asset inventory at proposed 45 CFR 164.308(a)(1)(i). Thus,
when the proposed new standard and implementation specifications are
read together, the written policies and procedures that govern the
receipt and removal of technology assets that maintain ePHI into and
out of a facility, and the movement of these assets within the
facility, should include tracking relevant information in the
technology asset inventory. Similarly, we are proposing to delete the
specification for data backup and storage because it is redundant to
the administrative safeguard on data backups at proposed 45 CFR
164.308(a)(13)(ii)(B).
As referenced above, in place of the implementation specifications
we are proposing to delete, the Department proposes a new
implementation specification at proposed 45 CFR 164.310(d)(2)(iii) that
would require a regulated entity to review and test the written
policies and procedures related to the implementation specifications
for technology assets at least once every 12 months or in response to
environmental or operational changes, whichever is more frequent, and
modify as reasonable and appropriate. Such environmental or operational
changes may range from new and emerging threats to the confidentiality,
integrity, or availability of ePHI (e.g., a new virus) to the adoption
of new technology assets by the regulated entity (e.g., a new operating
system, new types of workstations). Given the constant evolution of IT
and methods for restoring data that has been disposed of or was on
electronic media that has been sanitized, the Department believes that
it is essential for a regulated entity to at least consider the
reasonableness and appropriateness of its policies and procedures for
disposal and electronic media sanitation, not only annually, but also
in the face of any environmental or operational changes. We expect that
pursuant to our proposals to strengthen the standard for risk analysis,
a regulated entity would be able to identify such environmental and
operational changes before they occur.
4. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. Whether every 12 months is an appropriate frequency for review
of a regulated entity's written policies and procedures for physical
safeguards. If not, please explain.
b. Whether the written policies and procedures for physical
safeguards should be reviewed at different intervals, based on the
specific standard or implementation specification. If so, please
explain.
c. Whether the Department should include additional examples in
regulatory text at proposed 45 CFR 164.310(a)(2)(iv) of physical
components of a facility related to security for which there should be
written policies and procedures to document repairs and modifications.
d. Whether the standard at proposed 45 CFR 164.310(d)(1) and its
associated implementation specifications at paragraph (d)(2) should
apply to technology assets that do not maintain ePHI, but do access the
regulated entity's relevant electronic information systems.
F. Section 164.312--Technical Safeguards
1. Current Provisions
Section 164.312 includes five standards for technical safeguards,
which are the requirements concerning the implementation of technology
and technical policies and procedures to protect the confidentiality,
integrity, and availability of ePHI and related information systems. A
regulated entity must comply with the standards for technical
safeguards in accordance with 45 CFR 164.306(c), the provision that
describes the general rules for the security standards.
Under 45 CFR 164.312(a)(1), a regulated entity is required to
establish policies and procedures for electronic information systems to
allow access only to those persons or software programs that have been
granted access rights as specified in 45 CFR 164.308(a)(4). Regulated
entities may comply with this standard by implementing a combination of
access control methods and technical controls, consistent with the
implementation specifications for this standard. The Security Rule does
not identify a specific access control method or technology to
implement. Regardless of the technology or information system used,
access controls should be appropriate for the workforce member's role
and/or function.\659\ For example, a workforce member responsible for
monitoring and administering information systems with ePHI, such as an
administrator or a superuser,\660\ should only have access to ePHI as
appropriate for their role and/or job function.
---------------------------------------------------------------------------
\659\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 4.
\660\ A superuser is ``a user that is authorized (and therefore,
trusted) to perform security-relevant functions that ordinary users
are not authorized to perform.'' NIST definition of ``superuser,''
Glossary, Computer Security Resource Center, National Institute of
Standards and Technology, U.S. Department of Commerce, https://csrc.nist.gov/glossary/term/superuser.
---------------------------------------------------------------------------
The implementation specifications that provide instructions for
satisfying the access control standard are found at 45 CFR
164.312(a)(2). Two are required and two are addressable.\661\ The
implementation specifications address unique user identifiers,\662\
emergency access procedures,\663\ automatic logoff,\664\ and encryption
and decryption.\665\ The implementation
[[Page 963]]
specification for unique user identification requires a regulated
entity to assign unique identifiers to users to facilitate the
identification of specific users of an information system.\666\ By
assigning a unique identifier to each user, a regulated entity can
track the specific activity of that user when they are logged into an
information system and hold the user accountable for functions they
perform in the information system when they access that system.
---------------------------------------------------------------------------
\661\ See 45 CFR 164.306(d) for an explanation of ``required''
and ``addressable'' implementation specifications.
\662\ 45 CFR 164.312(a)(2)(i).
\663\ 45 CFR 164.312(a)(2)(ii).
\664\ 45 CFR 164.312(a)(2)(iii).
\665\ 45 CFR 164.312(a)(2)(iv).
\666\ 45 CFR 164.312(a)(2)(i).
---------------------------------------------------------------------------
Under the implementation specification for emergency access
procedures, a regulated entity is required to establish procedures,
such as documented operational practices and instructions to workforce
members, for obtaining access to necessary ePHI during an emergency and
to implement such procedures as needed.\667\ In accordance with this
implementation specification, a regulated entity must identify the
types of situations in which its normal procedures for accessing an
information system or application that contains ePHI may not work and
establish procedures for obtaining access in those situations.\668\
These procedures must be established prior to an emergency to instruct
workforce members on possible ways to gain access to needed ePHI where,
for example, the electrical system has been severely damaged or
rendered inoperative, or where a software update fails and prevents the
regulated entity from accessing ePHI in its EHR.
---------------------------------------------------------------------------
\667\ 45 CFR 164.312(a)(2)(ii).
\668\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 5.
---------------------------------------------------------------------------
The implementation specification for automatic logoff associated
with the standard for access control addresses the need for a regulated
entity to, when reasonable and appropriate, implement electronic
procedures that terminate an electronic session after a period of
inactivity.\669\ Automatic logoff is an effective way to prevent
unauthorized users from accessing ePHI on a workstation when it is left
unattended for a period of time.\670\ While many applications have
configuration settings that automatically log a user out of the system
after a period of inactivity, some systems have more limited
capabilities and may activate a screen saver that is password
protected.\671\
---------------------------------------------------------------------------
\669\ 45 CFR 164.312(a)(2)(iii).
\670\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 6.
\671\ Id.
---------------------------------------------------------------------------
The implementation specification under the standard for access
control addresses encryption and decryption and requires regulated
entities, when it is reasonable and appropriate, to implement a
mechanism to encrypt and decrypt ePHI.\672\ Encrypting data, including
ePHI, reduces the likelihood that anyone other than the party that has
the key to the encryption algorithm would be able to decrypt (i.e.,
translate) the data and convert it into plain, comprehensible
text.\673\
---------------------------------------------------------------------------
\672\ 45 CFR 164.312(a)(2)(iv).
\673\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 7.
---------------------------------------------------------------------------
The standard for audit controls requires a regulated entity to
implement hardware, software, and/or procedural mechanisms that record
and examine activity in electronic information systems that contain or
use ePHI. Most electronic information systems provide some level of
audit controls with a reporting method, such as audit reports.\674\
These controls are useful for recording and examining information
system activity, especially when determining whether a security
violation has occurred.\675\ The Security Rule does not identify data
that must be gathered by the audit controls or how often the audit
reports should be reviewed.\676\ Instead, a regulated entity must
consider its risk analysis and organizational factors, such as current
technical infrastructure and hardware and software security
capabilities, to determine reasonable and appropriate audit controls
for information systems that contain or use ePHI.\677\ The audit
controls standard has no implementation specifications.
---------------------------------------------------------------------------
\674\ ``Understanding the Importance of Audit Controls,''
Cybersecurity Newsletter, Office for Civil Rights, U.S. Department
of Health and Human Services, p. 1 (Jan. 2017), https://www.hhs.gov/sites/default/files/january-2017-cyber-newsletter.pdf?language=es.
\675\ Id.
\676\ Id. at 2.
\677\ Id.
---------------------------------------------------------------------------
Section 164.312(c)(1), the standard for integrity, requires a
regulated entity to implement policies and procedures to protect ePHI
from improper alteration or destruction. The integrity of data can be
compromised by both technical and non-technical sources. Workforce
members or business associates may make accidental or intentional
changes that improperly alter or destroy ePHI. Data can also be altered
or destroyed without human intervention, such as by electronic media
errors or failures.\678\ The purpose of this standard is to establish
and implement policies and procedures for protecting ePHI from being
compromised regardless of the source. Improperly altered or destroyed
ePHI can result in clinical quality problems for a covered entity,
including patient safety issues.\679\
---------------------------------------------------------------------------
\678\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 7.
\679\ Id.
---------------------------------------------------------------------------
Section 164.312(c)(2) contains the addressable implementation
specification for the integrity standard that requires a regulated
entity, when reasonable and appropriate, to implement electronic
mechanisms to corroborate that ePHI has not been altered or destroyed
in an unauthorized manner. To determine which electronic mechanisms
should be implemented to ensure the integrity of ePHI, a regulated
entity must consider the various risks to the integrity of ePHI
identified during the risk analysis. Once a regulated entity has
identified risks to the integrity of its data, it must identify
security measures that will reduce the risks.\680\
---------------------------------------------------------------------------
\680\ Id. at 9.
---------------------------------------------------------------------------
The standard for person or entity authentication at 45 CFR
164.312(d) requires a regulated entity to establish policies and
procedures for verifying that a person seeking access to ePHI is the
one claimed. This standard addresses technical controls for ensuring
access is allowed only to those persons or software programs that have
been granted access rights under the administrative safeguard for
information access management at 45 CFR 164.308(a)(4). This standard
has no implementation specifications.
Under the standard for transmission security at 45 CFR
164.312(e)(1), a regulated entity is required to implement technical
security measures to guard against unauthorized access to ePHI when
transmitted electronically, such as through the internet. A regulated
entity must identify the available and appropriate means to protect
ePHI as it is transmitted, select appropriate solutions, and document
its decisions.\681\
---------------------------------------------------------------------------
\681\ Id. at 10.
---------------------------------------------------------------------------
The two addressable implementation specifications for the
transmission security standards are under 45 CFR 164.312(e)(2). The
implementation specification for integrity controls requires a
regulated entity, when it is reasonable and appropriate, to implement
security measures to ensure that electronically transmitted ePHI is not
improperly modified without detection until the ePHI has been
disposed.\682\ The implementation specification for encryption requires
a regulated entity, when it is reasonable and appropriate, to implement
a mechanism to encrypt ePHI.
---------------------------------------------------------------------------
\682\ 45 CFR 164.312(e)(2)(i).
---------------------------------------------------------------------------
[[Page 964]]
2. Issues To Address
While the intention of 45 CFR 164.312 is for regulated entities to
develop and put into place technical controls, the Department is aware
that regulated entities have not always achieved the degree of
protection for ePHI that we intended. Absent a definition of
``implement,'' some regulated entities might interpret the term to mean
something other than implementing technical controls to ensure the
confidentiality, integrity, and availability of ePHI. This
misinterpretation may leave ePHI partially unprotected because
regulated entities may not implement safeguards throughout their
enterprise. As discussed above with respect to both the administrative
and physical safeguards, the Department is also concerned that
regulated entities are not making the connection between the
maintenance requirement at 45 CFR 164.306(d) and the requirement to
implement technical safeguards, and therefore, are not reviewing or
updating their policies and procedures for technical safeguards.
Additionally, the Department believes that regulated entities may not
be recognizing that their obligations under the Security Rule to
protect ePHI are not limited to protecting electronic information
systems that create, receive, maintain, or transmit ePHI, but
necessarily include other electronic information systems that affect
the confidentiality, integrity, or availability of ePHI.
While the Security Rule relies on a flexible and scalable approach
to compliance, the health care industry's shift to a digital
environment has substantially increased both the risk to ePHI and the
prevalence of technological solutions for addressing those risks.
Additionally, the cost of such solutions has, in many cases, decreased
over time, as is often the case with technology. For example, when the
original Security Rule was published, tools to encrypt ePHI had limited
availability, were more costly, and were not user-friendly,
particularly for small health care providers.\683\ By contrast, in
2024, the technical ability to encrypt data may be seamless in many
applications, inexpensive, and widely available in commercial software
and hardware products.\684\ Where an encryption solution is not
integrated into an application, software, or hardware, third-party
solutions are often available.\685\ Thus, we do not believe that it is
appropriate for such provisions to be ``addressable.'' \686\
---------------------------------------------------------------------------
\683\ 68 FR 8334, 8357 (Feb. 20, 2003).
\684\ For example, the ONC Health IT Certification Program
requires that certified health IT certified to the end-user device
encryption certification criterion at 45 CFR 170.315(d)(7) must
encrypt electronic health information stored on end-user devices
after use of the technology on those devices stops or prevent
electronic health information from being locally stored on end-user
devices after use of the technology on those devices stops. See also
``Security Standards: Technical Safeguards,'' supra note 343, p. 7.
\685\ ``How to Protect the Data that is Stored on Your
Devices,'' Cybersecurity & Infrastructure Security Agency, U.S.
Department of Homeland Security (access July 26, 2024), https://www.cisa.gov/resources-tools/training/how-protect-data-stored-your-devices; see also Karen Scarfone, et al., ``[Information Technology
Laboratory (ITL)] Bulletin: August 2020, Security Considerations for
Exchanging Files Over the internet,'' National Institute of
Standards and Technology, U.S. Department of Commerce (Aug. 2020),
https://csrc.nist.gov/files/pubs/shared/itlb/itlbul2020-08.pdf.
\686\ 45 CFR 164.306(d).
---------------------------------------------------------------------------
Based on its own investigations and compliance reviews, news
reports, and published studies, the Department is aware that many
regulated entities have failed to implement adequate technical
controls, or, in some cases, any technical controls. For example:
A large health system that operates in multiple States
experienced a massive data breach resulting from a hacking incident.
OCR's investigation found indications of potential failures to
sufficiently monitor its activity in its information systems that was
insufficient to protect against a cyberattack, implement an
authentication process to safeguard its ePHI, and have security
measures in place to protect ePHI from unauthorized access when it was
being transmitted electronically.\687\
---------------------------------------------------------------------------
\687\ ``Banner Health,'' supra note 567.
---------------------------------------------------------------------------
A Rhode Island nonprofit health system experienced a data
breach resulting from the theft of a laptop. OCR's investigation found
indications of potential failures to encrypt ePHI, despite the entity's
determination to implement encryption, and a lack of device and media
controls.\688\
---------------------------------------------------------------------------
\688\ Resolution Agreement, ``Lifespan,'' Office for Civil
Rights, U.S. Department of Health and Human Services (June 26,
2020), https://www.hhs.gov/sites/default/files/lifespan-ra-cap-signed.pdf.
---------------------------------------------------------------------------
At a large covered entity, workforce members used their
log-in credentials to access medical records maintained in the entity's
EHR without a job-related purpose.\689\ OCR's investigation found
evidence of potential violations of the requirement to implement
reasonable and appropriate policies and procedures to comply with the
standards, implementation specifications, or other requirements of the
Security Rule.\690\
---------------------------------------------------------------------------
\689\ Resolution Agreement, ``Yakima Valley Memorial Hospital,''
Office for Civil Rights, U.S. Department of Health and Human
Services (May 15, 2023), https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/yakima-ra-cap/index.html.
\690\ Id.
---------------------------------------------------------------------------
At another covered entity, the potential failure to
implement hardware, software, and/or procedural mechanisms that record
and examine activity in information systems that contain or use ePHI,
among other things, enabled a workforce member to sell the ePHI of more
than 12,000 individuals.\691\
---------------------------------------------------------------------------
\691\ See ``Montefiore Medical Center,'' supra note 248.
---------------------------------------------------------------------------
Some investigations have found indications that regulated entities
may implement technical controls that address some, but not all, users
of and technology assets in a relevant electronic information system,
such as software, hardware, and persons involved in the development,
configuration, and implementation of technical controls.\692\ And other
investigations have suggested that the potential failure of a regulated
entity to have security measures in place to protect ePHI from
unauthorized access when it is transmitted electronically has resulted
in increased risk and breaches of ePHI.\693\ Common network
segmentation practices would have substantially reduced the risk to the
security ePHI and could have prevented such breaches.
---------------------------------------------------------------------------
\692\ See, e.g., ``HHS Office for Civil Rights Settles HIPAA
Investigation with Arizona Hospital System Following Cybersecurity
Hacking,'' supra note 570.
\693\ Id.
---------------------------------------------------------------------------
Beyond the health care sector, threat actors have been able to gain
access to networks by compromising user accounts and taking advantage
of insufficient network segregation. For example, the 2014 Home Depot
breach involved the compromise of a third-party vendor's username and
password to enter Home Depot's network, which allowed hackers to obtain
elevated rights to navigate to self-checkout point-of-sale system.\694\
The Department is concerned about the potential effects of such
incidents in health care, where they would jeopardize the
confidentiality, integrity, and availability of ePHI.
---------------------------------------------------------------------------
\694\ ``The Home Depot Reports Findings in Payment Data Breach
Investigation,'' Home Depot (Nov. 6, 2014), https://ir.homedepot.com/news-releases/2014/11-06-2014-014517315.
---------------------------------------------------------------------------
Finally, consistent with the concerns expressed above about the
implications of recent caselaw and the uncertainty it might cause among
regulated entities assessing whether they have adequately protected
their ePHI, the Department is concerned that the existing Security Rule
may not provide sufficient instruction to regulated entities about
[[Page 965]]
how they must maintain specific security measures.
3. Proposals
The Department retains the requirements for technical safeguards
generally and proposes additions and modifications to the existing
standards and implementation specifications.
a. Section 164.312--Technical Safeguards
The Department proposes to expand the primary provision at 45 CFR
164.312 to clarify that regulated entities as a general matter must
implement and document the implementation of technical safeguards
adopted for compliance with the Security Rule. This proposal would
clarify that the requirement to implement and document technical
safeguards would apply to all technical safeguards, including technical
controls, implemented by a regulated entity to protect the
confidentiality, integrity, and availability of all ePHI it creates,
receives, maintains, or transmits.
As noted above, the current provision at 45 CFR 164.312 does not
reference the documentation requirements in 45 CFR 164.316. Therefore,
for clarity, we propose to explicitly require in 45 CFR 164.312 that
documentation of technical safeguards conforms to the requirements in
45 CFR 164.316. This proposed change would clarify that a regulated
entity must document the policies and procedures required to comply
with this rule and how entities considered the flexibility factors in
45 CFR 164.306(b). It would also clarify that a regulated entity must
document each action, activity, and assessment required by the Security
Rule. The Department considers the documentation requirements and other
provisions of 45 CFR 164.316 to apply to all of the safeguards,
including the technical safeguards, and this proposal is intended to
remove any potential uncertainty among regulated entities.
Additionally, we propose to add maintenance requirements separately to
the implementation specifications for particular technical safeguards
in 45 CFR 164.312, as discussed below and consistent with our proposals
to add similar requirements to particular administrative and physical
safeguards.
Additionally, as discussed above, the Department proposes to remove
the distinction between required and addressable implementation
specifications and make all implementation specifications required,
with specific, limited exceptions. Also as discussed above, we propose
to modify certain standards and implementation specifications to
clarify that the technical safeguards apply to ensure the
confidentiality, integrity, and availability of ePHI, which requires a
regulated entity to implement the technical safeguards in or on all
relevant electronic information systems. These proposals are discussed
in greater detail below.
b. Section 164.312(a)(1)--Standard: Access Control
The Department proposes to clarify the standard for access control
at 45 CFR 164.312(a)(1) by requiring a regulated entity to deploy
technical controls in relevant electronic information systems to allow
access only to those users and technology assets that have been granted
access rights. This proposed modification would ensure that a regulated
entity deploys technical controls, rather than solely ensuring that it
implements technical policies and procedures, consistent with our
proposals to define ``deploy'' and ``implement.'' \695\ Thus, the
proposal would clarify that a regulated entity is not expected to
merely establish a policy and procedure, but must also put into place,
ensure the operation of, and verify the continued operation of,
technical controls for access to its relevant electronic information
systems such that the failure to have such technical control in
operation throughout its enterprise would be a violation of the new
proposed standard. Additionally, the Department's proposal would
clarify that access controls would apply to persons with authorized
access and to technology assets.
---------------------------------------------------------------------------
\695\ See 45 CFR 164.304 (proposed definitions of ``Deploy'' and
``Implement'').
---------------------------------------------------------------------------
Access controls are one of the key mechanisms by which a regulated
entity protects ePHI. Such technical controls ensure that access to the
regulated entity's electronic information systems is limited to only
users and technology assets that have been granted access rights under
the policies and procedures adopted in accordance with the standard for
information access management under 45 CFR 164.308.\696\ The Security
Rule does not identify a specific type of access control method or
technology to deploy, nor are we proposing to do so in this rule.\697\
As discussed above, access rights should be role-based and the
technical controls should assist the regulated entity in implementing
such policies and procedures. For example, workforce members
responsible for monitoring and administering a regulated entity's
relevant electronic information systems, such as someone responsible
for cybersecurity or providing technical support to users, must only
have access to ePHI and to the regulated entity's relevant electronic
information systems as appropriate for their role and job function.
---------------------------------------------------------------------------
\696\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 3.
\697\ Id. at 4.
---------------------------------------------------------------------------
We also propose at 45 CFR 164.312(a)(1) to add a paragraph heading
to clarify the organization of the regulatory text.
The Department proposes to modify the existing implementation
specifications under the standard for access control and to add five
new implementation specifications. Additionally, we propose to
redesignate the implementation specification for encryption and
decryption as a standard.
We propose to modify the implementation specification for unique
user identification at 45 CFR 164.312(a)(2)(i) by renaming the
implementation specification as ``Unique identification'' and adding a
requirement to assign a unique identifier for tracking each technology
asset. These proposed modifications would clarify for regulated
entities that the purpose of this requirement is to enable a regulated
entity to identify and track unauthorized activity in its relevant
electronic information systems. Such unauthorized activity may include
activity by unauthorized persons or technology assets. It may also
include activity by persons who are authorized to access the regulated
entity's relevant information systems but who access ePHI that they do
not need to access for their job or function.
The Department also proposes to expand the types of identifiers a
regulated entity may assign to users and technology assets beyond names
to include numbers and/or other identifiers and to clarify that a
unique identifier must be assigned to each user and technology asset in
the regulated entity's relevant electronic information systems. This
proposed modification would better meet the goals of this
implementation specification by requiring a regulated entity to be able
to discern and track activities among all users and technology assets,
regardless of whether that user or technology asset is a person,
hardware, software program, or device. The proposed implementation
specification for unique identification aligns with the Department's
essential CPG for Unique Credentials, which calls for regulated
entities to use unique credentials to
[[Page 966]]
help detect and track anomalous activities.\698\
---------------------------------------------------------------------------
\698\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
Additionally, we propose to add an implementation specification at
proposed 45 CFR 164.312(a)(2)(ii) for administrative and increased
access privileges. Access controls should enable an authorized user to
access the minimum necessary information needed to perform their job
functions.\699\ Rights and/or privileges should be granted to
authorized users based on the policies and procedures required under
the administrative safeguard for information access management.\700\
For example, a workforce member who has certain role-based
administrative access privileges should have separate user identities
for non-administrative access privileges and administrative access
privileges. Separating a single workforce member's user identities
based on access privilege substantially limits the risk that an
intruder will be able to access ePHI through a workforce member's user
identity when they are using the administrative access privileges.\701\
A regulated entity may be able to improve the control and review of the
use of administrative access privileges, such as through a privileged
access management system, to understand how privileged accounts are
used within its environment and help detect and prevent the misuse of
privileged accounts.\702\
---------------------------------------------------------------------------
\699\ Id. at 3-4.
\700\ See 45 CFR 164.308(a)(4) and proposed 45 CFR
164.308(a)(10).
\701\ See ``Controlling Access to ePHI: For Whose Eyes Only?,''
supra note 416.
\702\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
---------------------------------------------------------------------------
The proposed implementation specification would require a regulated
entity to separate the unique user identities required by the
implementation specification for unique user identification based on
the type of access privileges used by a specific unique user. For
example, the adoption of health IT that is certified through the ONC
Health IT Certification Program as having the technical capability to
establish user permissions for accessing, and performing actions with,
electronic health information based on unique identifiers may
contribute to a regulated entity's compliance with the proposed new
implementation specification for administrative and increased access
privileges, should the proposal be finalized.\703\ This proposed new
implementation specification aligns with the Department's essential CPG
for Separate User and Privileged Accounts by addressing the separation
of privileged or administrator access rights from common user
accounts.\704\
---------------------------------------------------------------------------
\703\ See 45 CFR 170.315(d)(1).
\704\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
Additionally, the Department proposes to redesignate the
implementation specification for emergency access procedures at 45 CFR
164.312(a)(2)(ii) as proposed 45 CFR 164.312(a)(2)(iii) and to modify
it to require a regulated entity to establish both written procedures
and technical procedures for obtaining necessary ePHI during an
emergency and to implement them as needed. For example, we note that
the adoption of health IT that is certified through the ONC Health IT
Certification Program as having the technical capability to permit an
identified set of users to access electronic health information during
an emergency may contribute to a regulated entity's compliance with the
proposed implementation specification for emergency access procedures,
should the proposal be finalized.\705\
---------------------------------------------------------------------------
\705\ See 45 CFR 170.315(d)(6).
---------------------------------------------------------------------------
Under the Department's proposal, the implementation specification
for automatic logoff at 45 CFR 164.312(a)(2)(iii) would be redesignated
as proposed 45 CFR 164.312(a)(2)(iv) and modified to require a
regulated entity to deploy technical controls that terminate an
electronic session after a period of inactivity. Deploying a mechanism
to automatically terminate an electronic session after a period of
inactivity reduces the risk of unauthorized access when a user forgets
or is unable to terminate their session.\706\ Failure to deploy
automatic logoff not only increases the risk of unauthorized access and
potential alteration or destruction of ePHI; it also impedes an
organization's ability to properly investigate such unauthorized access
because it would appear to originate from an authorized user.\707\
---------------------------------------------------------------------------
\706\ ``Controlling Access to ePHI: For Whose Eyes Only?,''
supra note 416.
\707\ Id.
---------------------------------------------------------------------------
The Department proposes that the period of inactivity be both
predetermined and reasonable and appropriate. When determining the
length of the period of inactivity, a regulated entity should consider
the access privileges of a given user or technology asset, the
system(s) being accessed, the environment in which the system access
occurs, and other appropriate factors in determining a reasonable and
appropriate time of inactivity before session termination. For example,
in an emergency setting, a user may not have time to manually log out
of a system. User identities with administrative and other high-level
access that present a greater risk to the confidentiality, integrity,
and availability of ePHI should have appropriately shorter periods of
inactivity because of the increased risk. While many applications have
configuration settings for automatic logoff,\708\ a regulated entity
must determine whether the default automatic logoff is reasonable and
appropriate and make modifications if it is not. For example, the
adoption of health IT that is certified through the ONC Health IT
Certification Program as having the technical capability to
automatically stop a user's access to health information after
inactivity for a predetermined period and require a user to re-enter
their credentials to resume or regain access may contribute to a
regulated entity's compliance with the proposed implementation
specification for automatic logoff, should the proposal be
finalized.\709\
---------------------------------------------------------------------------
\708\ For example, Windows 10 operating system allows users to
customize security options to automatically logout a user after a
specified period of inactivity.
\709\ See 45 CFR 170.315(d)(5).
---------------------------------------------------------------------------
Additionally, we propose to add an implementation specification for
log-in attempts at proposed 45 CFR 164.312(a)(2)(v). The proposal would
require a regulated entity to deploy technical controls that disable or
suspend the access of a user or technology asset to relevant electronic
information systems after a certain number of unsuccessful
authentication attempts. Although incorrectly keying in a known
password by the intended user may occur infrequently, a repeated and
persistent failure is a strong indication of an attempt at unauthorized
access. For example, brute force attacks are attempts to gain
unauthorized access by guessing the password many times in a row.\710\
Technical controls that limit the number of incorrect log-in attempts
by disabling or suspending the access of a user or technology asset to
relevant electronic information systems are appropriate to address
unsuccessful login attempts.\711\
---------------------------------------------------------------------------
\710\ ``Brute Force Attacks Conducted by Cyber Actors,''
Cybersecurity & Infrastructure Security Agency, U.S. Department of
Homeland Security (May. 6, 2020), https://www.cisa.gov/news-events/alerts/2018/03/27/brute-force-attacks-conducted-cyber-actors.
\711\ ``Security and Privacy Controls for Information Systems
and Organizations,'' supra note 600, p. 39.
---------------------------------------------------------------------------
The proposal would require a regulated entity to determine the
number of unsuccessful authentication attempts that would trigger
disabling or suspending access to relevant electronic information
system. The number should
[[Page 967]]
be reasonable and appropriate for the type of user or technology asset,
the electronic information system or technology asset to which access
is sought, and the type of information maintained on such information
system or technology asset. For example, a regulated entity may
determine that any authentication failure of an administrative
privileged access account should disable the account because of the
level of risk compared to an authentication failure of a non-
administrative privileged account. The Department does not propose to
define disable or suspend and relies upon the industry understanding
that disabling a user's access would require intervention to restore
the capability to use the user identity, while a suspension may prevent
additional log-in attempts for a temporary, limited period of time.
Consistent with NCVHS' recommendation and existing guidance, the
Department also proposes to add an implementation specification for
network segmentation at 45 CFR 164.312(a)(2)(vi) that would require a
regulated entity to deploy technical controls to segment its relevant
electronic information systems in a reasonable and appropriate
manner.\712\ Under this proposal, a regulated entity with multiple,
distinct electronic information systems would be required to separate
relevant electronic information systems using reasonable and
appropriate technical controls. Network segmentation is a physical or
virtual division of a network into multiple segments, creating
boundaries between the operational and IT networks to reduce risks,
such as threats caused by phishing attacks.\713\ For example, where a
regulated entity operates both a point-of-sale system and an EHR on the
same network, the EHR could be compromised through a successful attack
by an intruder moving laterally (i.e., within the same network) from a
previously compromised point-of-sale system because the intruder's
movements were not impeded by network segmentation. Accordingly, we
believe that it is appropriate to require regulated entities to deploy
technical controls to segment the networks to which their relevant
electronic information systems are connected.\714\ What constitutes
reasonable and appropriate network segmentation depends on the
regulated entity's risk analysis and how it has implemented its
network(s) and relevant electronic information systems. This proposed
new implementation specification aligns with the Department's enhanced
CPG for Network Segmentation because where the CPG is implemented, an
intruder's ability to freely move within a regulated entity's network
and protect ePHI is minimized.\715\
---------------------------------------------------------------------------
\712\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 3 (recommending that the Department require
network segmentation as part of a layered security approach,
segregating network components based on user characteristics, such
as corporate network compared to business associate network);
``Layering Network Security Through Segmentation,'' Cybersecurity &
Infrastructure Security Agency, U.S. Department of Homeland
Security, https://www.cisa.gov/sites/default/files/publications/layering-network-security-segmentation_infographic_508_0.pdf;
``Health Industry Cybersecurity Practices: Managing Threats and
Protecting Patients,'' supra note 16, pp. 23 and 31; PR.IR-01, ``The
NIST Cybersecurity Framework (CSF) 2.0,'' supra note 15.
\713\ ``Layering Network Security Through Segmentation,'' supra
note 712.
\714\ Letter from NCVHS Chair Jacki Monson (2023), supra note
123, Appendix p. 3.
\715\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
The proposed implementation specification for data controls at
proposed 45 CFR 164.312(a)(2)(vii) would require a regulated entity to
deploy technical controls to allow access to ePHI based on the
regulated entity's policies and procedures for granting users and
technology assets access relevant electronic information systems as
specified in proposed 45 CFR 164.308(a)(10). This implementation
specification would require a regulated entity to have in place
technical controls that distinguish between users and technology
assets, that are permitted to access the regulated entity's relevant
electronic information systems and those that are not permitted to do
so and would require that the controls permit or disallow access
accordingly.
Properly deployed network-based solutions can limit the ability of
a hacker to gain access to an organization's network or impede the
ability of a hacker already in the network from accessing other
electronic information systems--especially systems containing sensitive
data.\716\ Access controls could include role-based access, user-based
access, or any other access control mechanisms the organization deems
appropriate.\717\ Access controls need not be limited to computer
systems--firewalls, network segmentation, and network access control
solutions are effective means of limiting access to relevant electronic
information systems.\718\
---------------------------------------------------------------------------
\716\ ``Controlling Access to ePHI: For Whose Eyes Only?,''
supra note 416.
\717\ Id.
\718\ Id.
---------------------------------------------------------------------------
Additionally, we propose to add an implementation specification for
maintenance at proposed 45 CFR 164.312(a)(2)(viii). Under this
proposal, a regulated entity would be expressly required to review and
test the effectiveness of the procedures and technical controls
required by the implementation specifications associated with the
standard for access control at least once every 12 months or in
response to environmental or operational changes, whichever is more
frequent, and modify as reasonable and appropriate.
c. Section 164.312(b)(1)--Standard: Encryption and Decryption
Encryption can reduce the risks and costs of unauthorized access to
ePHI.\719\ For example, if a hacker gains access to unsecured ePHI on a
network server or if a device containing unsecured ePHI is stolen, a
breach of PHI will be presumed and reportable under the Breach
Notification Rule.\720\ The Breach Notification Rule applies to
unsecured PHI, which is PHI that is not rendered unusable, unreadable,
or indecipherable to unauthorized persons through the use of a
technology or methodology specified by the Secretary in guidance issued
under the HITECH Act.\721\ The Department's guidance on rendering
unsecured PHI unusable, unreadable, or indecipherable to persons who
are not authorized to access such PHI states that ePHI at rest (i.e.,
stored in an information system or electronic media) is considered
secured if it is encrypted in a manner consistent with NIST Special
Publication 800-111 \722\ (``SP 800-111''). The ePHI encrypted in a
manner consistent with SP 800-111 is not considered unsecured PHI and
therefore qualifies for what is commonly known as the Breach
Notification safe harbor, meaning that it is not subject to the
requirements of the Breach Notification Rule.\723\ Thus, by encrypting
ePHI in a manner consistent with the Secretary's guidance, a regulated
entity may not only fulfill its encryption obligation under the
Security Rule, but also make use of the
[[Page 968]]
Breach Notification Rule's safe-harbor provision.\724\
---------------------------------------------------------------------------
\719\ Id.
\720\ See 45 CFR 402. The presumption applies unless it can be
rebutted in accordance with the breach risk assessment described in
45 CFR 164.402(2).
\721\ 45 CFR 164.402.
\722\ Karen Scarfone, et al., ``Guide to Storage Encryption
Technologies for End User Devices: Recommendations of the National
Institute of Standards and Technology,'' NIST Special Publication
800-111, National Institute of Standards and Technology, U.S.
Department of Commerce (Nov. 2007), https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-111.pdf.
\723\ 74 FR 19600, 19009-19010 (Apr. 27, 2009).
\724\ 45 CFR 164.402.
---------------------------------------------------------------------------
As the use of mobile computing devices (e.g., laptops, smartphones,
tablets) has become more pervasive, the risks to sensitive data stored
on such devices also have increased.\725\ And while in 2003 and even in
2013, encryption might have been out of reach for many regulated
entities because of cost or a similar reason,\726\ today, encryption
solutions are generally considered to be widely accessible. The cost of
such solutions has decreased significantly, as has the difficulty in
implementing such solutions. In fact, many applications have encryption
solutions embedded in them.\727\ Once enabled, a device's encryption
solution can protect stored sensitive data, including ePHI, from
unauthorized access in the event the device is lost or stolen. The same
is true for most software today.\728\ Thus, while encryption of a
particular regulated entity's ePHI might not have been reasonable and
appropriate in 2003 or 2013, the Department believes encryption
generally is reasonable and appropriate today.\729\
---------------------------------------------------------------------------
\725\ ``Controlling Access to ePHI: For Whose Eyes Only?,''
supra note 416.
\726\ See 68 FR 8334, 8357 (Feb. 20, 2003).
\727\ ``Controlling Access to ePHI: For Whose Eyes Only?,''
supra note 416.
\728\ Id.
\729\ See discussion of 45 CFR 164.312, infra.
---------------------------------------------------------------------------
Because the prevalence of encryption solutions has increased, as
has their affordability and the role they play in protecting
information, including ePHI, the Department believes it is appropriate
to consider requiring encryption and elevating it from an
implementation specification to a standard to increase its visibility
and prominence. Based on this and consistent with NCVHS'
recommendation, the Department proposes to redesignate the
implementation specification for encryption and decryption at 45 CFR
164.312(a)(2)(iv) as a standard at proposed 45 CFR 164.312(b)(1).\730\
The proposed standard would incorporate the requirements of two
implementation specifications that address encryption--the one
addressed here and the one at 45 CFR 164.312(e)(2)(ii).\731\ The
Department proposes that the new standard would require a regulated
entity to configure and implement technical controls to encrypt and
decrypt all ePHI in a manner that is consistent with prevailing
cryptographic standards. This proposed new standard aligns with the
Department's essential CPG for Strong Encryption by calling for
regulated entities to deploy encryption to protect ePHI and with the
recommendation of NCVHS.\732\ We also note that the adoption of health
IT that is certified through the ONC Health IT Certification Program as
having the technical capability to encrypt and decrypt electronic
health information, using an encryption algorithm that meets certain
requirements, may contribute to a regulated entity's compliance with
the proposed standard for encryption and decryption, should the
proposal be finalized.\733\
---------------------------------------------------------------------------
\730\ Letter from NCVHS Chair Jacki Monson (2023), supra note
123, Appendix p. 2.
\731\ The Department is also proposing to delete the
implementation specification for encryption at 45 CFR
164.312(e)(2)(ii) because we are proposing to address the
substantive requirements of that implementation specification in
proposed 45 CFR 164.312(b)(2).
\732\ ``Cybersecurity Performance Goals,'' supra note 18; Letter
from NCVHS Chair Jacki Monson (2023), supra note 123, Appendix p. 2.
\733\ See 45 CFR 170.315(d)(7) and 170.210(a).
---------------------------------------------------------------------------
Under the proposal, a regulated entity would need to ensure that an
encryption solution that it adopts meets prevailing cryptographic
standards prior to using it. The Department uses the phrase
``prevailing cryptographic standards'' to refer to widely accepted
standards for encryption and decryption that are recommended by
authoritative sources and that ensure the confidentiality, integrity,
and availability of ePHI at the time the regulated entity performs its
risk analysis and establishes or modifies its risk management plan. The
Department would expect a regulated entity to deploy updated encryption
solutions as prevailing cryptographic standards evolve, consistent with
both of the proposed requirements discussed above: (1) to review,
verify, and update its risk analysis in response to changes in its
environment that may affect ePHI; and (2) to review and modify, as
reasonable and appropriate, its risk management plan in response to
changes in its risk analysis. Thus, a regulated entity using an
encryption algorithm that is known to be insecure would not be in
compliance with the proposed requirement to deploy an encryption
algorithm that meets prevailing cryptographic standards. We are not
proposing to define prevailing cryptographic standards in regulatory
text at this time.
The Department proposes to add one implementation specification for
the proposed standard for encryption and decryption. Specifically,
proposed 45 CFR 164.312(b)(2) would require regulated entities to
encrypt all ePHI at rest and in transit, with limited exceptions.\734\
Thus, a regulated entity would be required to encrypt all ePHI it
maintains, as well as all ePHI it transmits, unless an exception
applies, and the following conditions are met:
---------------------------------------------------------------------------
\734\ For example, adoption of health IT that is certified
through the ONC Health IT Certification Program as having the
technical capability to encrypt, or prevent the local storage of,
electronic health information stored on end-user devices after use
of the technology on those devices stops may contribute to a
regulated entity's compliance with the proposed implementation
specification for encryption and decryption. See 45 CFR
170.315(d)(7). Additionally, the proposed implementation
specification generally is consistent with the Health Data,
Technology, and Interoperability: Patient Engagement, Information
Sharing, and Public Health Interoperability (HTI-2) NPRM proposal to
modify 45 CFR 170.315(d)(7), should it be finalized, to include
requirements that authentication credentials be protected using
industry-standard encryption and decryption. See 89 FR 63536-37,
63778 (Aug. 5, 2024).
---------------------------------------------------------------------------
Each exception applies only to the ePHI directly affected
by the circumstances described in the specific exception.
Each exception applies only to the extent that the
regulated entity documents its understanding that the exception applies
to the scenario in which the regulated entity relies upon the exception
and why or how the exception applies, and that any additional
applicable conditions are met.
The first proposed exception at proposed 45 CFR 164.312(b)(3)(i)
would apply to a technology asset currently used by a regulated entity
that does not support encryption according to prevailing cryptographic
standards. Because the requirements for encryption under the Security
Rule today are addressable, a regulated entity may be in compliance
with the encryption requirement without actual encryption of ePHI if
encryption is not reasonable and appropriate, provided that the entity
meets certain conditions. Additionally, technology assets in use today
may rely on cryptographic standards that are no longer accepted
industry practice. The Department recognizes that it may take some time
for a regulated entity to adopt compliant technology assets. Thus, we
propose this exception for such technology assets that do not support
encryption consistent with prevailing cryptographic standards in
limited circumstances. Specifically, to meet this exception, a
regulated entity would be required to establish a written plan to
migrate ePHI to technology assets that support encryption consistent
with prevailing cryptographic standards and to implement such plan. The
regulated entity would be required to establish and implement the
written plan within
[[Page 969]]
a reasonable and appropriate period of time. For example, it would not
be reasonable or appropriate for a regulated entity to establish a plan
to migrate ePHI on a single flash drive within 30 days and not complete
migration of that ePHI for a period of a year because migrating ePHI
from a flash drive to a more secure medium is a simple and quick
process that the regulated entity already determined could be completed
within 30 days. Thus, a year would be an unreasonably long period to
leave ePHI insufficiently encrypted, particularly after a need to
migrate the ePHI has been established. In such circumstances, the
regulated entity would not be complying with the requirements of this
proposed exception.
The second proposed exception at proposed 45 CFR 164.312(b)(3)(ii)
would be available for ePHI transmitted in response to an individual
request, pursuant to 45 CFR 164.524, to receive their ePHI in an
unencrypted manner. Unencrypted manners for an individual to receive
their ePHI may include some types of text messaging, instant messaging,
and other applications on a smartphone or another computing device that
are capable of making an access request and receiving ePHI.\735\ This
exception for individual access requests under 45 CFR 164.524 would not
apply when the individual would receive their ePHI using technology
controlled by the regulated entity, such as a patient portal \736\ or
other technology for the transmission of ePHI (e.g., API
technology).\737\ Such email or messaging technologies are considered
to be among a covered entity's technology assets because they are
components of a covered entity's relevant electronic information
systems, and the requirement to encrypt ePHI would apply.
---------------------------------------------------------------------------
\735\ Messaging in the context of telehealth is discussed in
Department guidance on telehealth. See ``Guidance on How the HIPAA
Rules Permit Covered Health Care Providers and Health Plans to Use
Remote Communication Technologies for Audio-Only Telehealth,''
Office for Civil Rights, U.S. Department of Health and Human
Services (June 13, 2022), https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-audio-telehealth/index.html.
\736\ For example, health IT certified through the ONC Health IT
Certification Program as meeting the ``[v]iew, download, and
transmit to 3rd party'' certification criterion must be able to
create and transmit continuity of care document summaries to
patients through email via an encrypted method of electronic
transmission. See 45 CFR 170.315(e)(1).
\737\ The ONC Health IT Certification Program sets forth 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 ACBs must ensure are also
included as part of specific Health IT Modules that are presented
for certification. For example, to meet the ``[s]tandardized API for
patient and population services'' certification criterion, the ONC
Health IT Certification Program requires that a Health IT Module
presented for testing and certification must demonstrate the ability
to establish a secure and trusted connection with an application
requesting data for patients. See 45 CFR 170.315(g)(10); see also 45
CFR 170.215.
---------------------------------------------------------------------------
Under the right of access, an individual who is the subject of PHI
has the right to inspect and request a copy of PHI about them in a
designated record set, subject to certain exceptions. A regulated
entity is required to provide such access in the form and format
requested by the individual, if it is readily producible in such form
and format. Thus, if an individual requests that the regulated entity
provide them access in a manner that does not support encryption, a
regulated entity is generally required to do so if it does not
jeopardize the security of the regulated entity's information systems.
For the exception to apply, a regulated entity would be required to
have informed the individual of the risks associated with the
transmission, receipt, and storage of unencrypted ePHI when the
individual requests unencrypted access and to document that the
individual has been informed of such risks.\738\
---------------------------------------------------------------------------
\738\ See ``Resource for Health Care Providers on Educating
Patients about Privacy and Security Risks to Protected Health
Information when Using Remote Communication Technologies for
Telehealth,'' Office for Civil Rights, U.S. Department of Health and
Human Services, (Oct. 17, 2023), https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/resource-health-care-providers-educating-patients/index.html.
---------------------------------------------------------------------------
Consistent with the information blocking regulations, the
information provided by regulated entities that are also actors must:
focus on any current privacy and/or security risks posed by the
technology or the third-party developer of the technology; be factually
accurate, unbiased, objective, and not unfair or deceptive; and be
provided in a non-discriminatory manner.\739\ For example, a regulated
entity that is an actor must provide information to individuals about
the privacy and security risks of all mobile health applications in the
same manner.
---------------------------------------------------------------------------
\739\ See 45 CFR part 171; 85 FR 25642, 25815 (May 1, 2020).
---------------------------------------------------------------------------
We are not proposing to require that the documentation be in any
particular form or format. Rather, the required information could be on
a standard form, chart note, or checkbox, as examples. The Department
does not propose to apply this exception to ePHI transmitted in other
forms or formats, such as on a CD or other physical device used to
maintain and transmit ePHI. The proposal would not absolve a regulated
entity from compliance with other applicable laws or regulations,
including the information blocking regulations.\740\
---------------------------------------------------------------------------
\740\ See, e.g., 45 CFR part 171.
---------------------------------------------------------------------------
We recognize that emergencies or other occurrences may render it
infeasible to encrypt ePHI. Thus, the third proposed exception at 45
CFR 164.312(b)(3)(iii) would apply to certain circumstances in which
encryption is infeasible. Such circumstances would be limited to when
there is emergency or other occurrence that adversely affects a
regulated entity's relevant electronic information systems. For the
proposed exception to apply, a regulated entity would be required to
implement reasonable and appropriate compensating controls in
accordance with and determined by its contingency plan.\741\ The
Department would expect this proposed exception to be applicable for a
limited period of time and only when encryption is infeasible. As noted
above, the proposed exception to encryption would narrowly apply only
when a regulated entity's relevant electronic information system is
adversely affected by the emergency or other occurrence. The proposed
exception would no longer be applicable at such time encryption becomes
feasible, regardless of whether the emergency or other occurrence
continues.
---------------------------------------------------------------------------
\741\ 45 CFR 164.308(a)(13).
---------------------------------------------------------------------------
The fourth proposed set of exceptions at proposed 45 CFR
164.312(b)(3)(iv) would be for ePHI that is created, received,
maintained, or transmitted by a medical device (i.e., a ``device''
within the meaning of section 201(h) of the Federal Food, Drug, and
Cosmetic Act, 21 U.S.C. 321(h)) that is authorized by the FDA for
marketing. We propose three separate exceptions for devices that are
authorized by the FDA for marketing pursuant to: a submission received
before March 29, 2023; a submission received on or after March 29,
2023, where the device is no longer supported by its manufacturer; or a
submission received on or after March 29, 2023, where the device is
supported by its manufacturer. Where a device has been authorized by
the FDA for marketing pursuant to a submission received before March
29, 2023, we propose that the exception at proposed 45 CFR
164.312(b)(3)(iv)(A) would be available only where the regulated entity
deploys in a timely manner any updates or patches required or
recommended by the manufacturer of the device. We also propose a
similar exception at proposed 45 CFR 164.312(b)(3)(iv)(B) for devices
authorized by the FDA for marketing pursuant to a submission received
on or
[[Page 970]]
after March 29, 2023, where the device is no longer supported by its
manufacturer, provided that the regulated entity has deployed any
updates or patches required or recommended by the manufacturer.
We recognize that, to comply with this proposal, some regulated
entities may incur costs for replacing legacy medical devices (i.e.,
medical devices that cannot be reasonably protected against current
cybersecurity threats).\742\ We also recognize that legacy devices can
pose significant risks to the confidentiality, integrity, and
availability of ePHI.\743\ By limiting these exceptions to devices that
have been updated and/or patched while they were supported by their
manufacturer, we believe that this proposal would balance the interest
in encouraging regulated entities to dispense with legacy devices with
the cost of replacing such devices. Additionally, the Department
believes that regulated entities should already have plans to replace
legacy devices that cannot be made cybersecure because of their
existing Security Rule obligations. We also recognize that at some
point, most, if not all, devices will likely become legacy devices and
that there may be legitimate reasons not to immediately replace them
when the manufacturer ceases to provide support. In such cases, it will
continue to be important for regulated entities to plan for how to
address their ongoing Security Rule obligations.
---------------------------------------------------------------------------
\742\ See ``Next Steps Toward Managing Legacy Medical Device
Cybersecurity Risks,'' MITRE Corporation (Nov. 2023), https://www.mitre.org/sites/default/files/2023-11/PR-23-3695-Managing-Legacy-Medical-Device%20Cybersecurity-Risks.pdf; ``Principles and
Practices for the Cybersecurity of Legacy Medical Devices,''
International Medical Device Regulators Forum, p. 8 (Apr. 11, 2023),
https://www.imdrf.org/sites/default/files/2023-04/IMDRF%20Principles%20and%20Practices%20
of%20Cybersecurity%20for%20%20Legacy%20
Medical%20Devices%20Final%20%28N70%29_1.pdf.
\743\ ``Cybersecurity,'' U.S. Food & Drug Administration, U.S.
Department of Health and Human Services, https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity.
---------------------------------------------------------------------------
Finally, we propose an exception, proposed 45 CFR
164.312(b)(3)(iv)(C), that would be available for a device authorized
by the FDA for marketing pursuant to a submission received on or after
March 29, 2023, where the device is supported by its manufacturer. We
understand that the FDA considers security during the review of medical
device marketing submissions, including those for software that is
approved as a medical device, and works with device manufacturers to
ensure that appropriate cybersecurity protections are built into such
devices, pursuant to FDA's authority under the Consolidated
Appropriations Act, 2023.\744\ Thus, we do not believe it would be
necessary or appropriate for the Security Rule to require encryption
for an FDA-authorized medical device that has been authorized by the
FDA for marketing pursuant to a submission received on or after March
29, 2023 where the device continues to be supported by its
manufacturer.
---------------------------------------------------------------------------
\744\ See sec. 3305 of Public Law 117-328, 126 Stat. 5832 (Dec.
29, 2022) (codified at 21 U.S.C. 360n-2); see also ``Cybersecurity
in Medical Devices Frequently Asked Questions (FAQs),'' U.S. Food &
Drug Administration, U.S. Department of Health and Human Services,
https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-
faqs.
---------------------------------------------------------------------------
Where a proposed exception applies to the proposed encryption
requirement, the Department also proposes to require that a regulated
entity implement alternative measures and compensating controls.
Specifically, we propose at proposed 45 CFR 164.312(b)(4)(i) to require
a regulated entity to document the existence of an applicable exception
and implement reasonable and appropriate compensating controls. Under
the proposal, we would require documentation to occur in real-time,
meaning when the criteria for the exception exist and at the time
compensating controls are implemented. For example, a regulated entity
disclosing ePHI to an individual by unencrypted email in accordance
with the right of access would be required to document in accordance
with the proposed 45 CFR 164.312(b)(4)(i) that: (1) before the
disclosure, the individual has requested to receive ePHI by unencrypted
email or unencrypted messaging technology; and (2) before the
disclosure, the regulated entity informed the individual of the risks
associated with transmission of unencrypted ePHI. The exception would
not apply where such individual requests to receive access to their
ePHI pursuant to 45 CFR 164.524 via email or messaging technologies
implemented by the covered entity.
At proposed 45 CFR 164.312(b)(4)(i), the Department proposes to
require that where a proposed exception applies, a regulated entity
would also be required to implement an alternative measure or measures
that are reasonable and appropriate compensating controls under
proposed 45 CFR 164.312(b)(4)(ii). Compensating controls would be
implemented in the place of encryption to protect ePHI from
unauthorized access.\745\ The Department does not propose to require
that compensating controls be limited to technical controls. Rather, a
regulated entity should consider the nature of the exception, operating
environment, and other appropriate circumstances to determine what
controls are reasonable and appropriate and implement compensating
controls effective for those circumstances. For example, a regulated
entity may use physical access controls, such as physically limiting
access to a device, in combination with other controls to compensate
for the absence of encryption.
---------------------------------------------------------------------------
\745\ Celia Paulsen, et al., ``Glossary of Key Information
Security Terms,'' NIST Interagency and Internal Reports 7298,
Revision 3, National Institute of Standards and Technology, U.S.
Department of Commerce (July 3, 2019), https://nvlpubs.nist.gov/nistpubs/ir/2019/NIST.IR.7298r3.pdf.
---------------------------------------------------------------------------
Proposed paragraph (b)(4)(ii)(A) would require that if the
regulated entity has determined that an exception applies, it must
secure ePHI by implementing reasonable and appropriate compensating
controls that are reviewed and approved by the regulated entity's
designated Security Official. Because exceptions are a departure from
the Security Rule framework, the Department proposes to ensure
appropriate focus and review by the Security Official of the controls
chosen to compensate for the absence of encryption.
With respect to the exception at proposed 45 CFR
164.312(b)(3)(iv)(C), the Department proposes at paragraph
(b)(4)(ii)(B) to presume that a regulated entity had implemented
reasonable and appropriate compensating controls where the regulated
entity has deployed the security measures prescribed and as instructed
by the FDA-authorized label for the device. This would include any
updates, including patches recommended or required by the manufacturer
of the device. The proposed language recognizes that while the device's
label may not specifically require deployment of an encryption
solution, it may provide for a specific compensating control and the
manner in which that control is to be implemented. While not required,
a regulated entity would be permitted to implement additional
alternative security measures and compensating controls in accordance
with best practices and/or its risk analysis.
Finally, at proposed paragraph (b)(4)(ii)(C), the Department
proposes to require that the regulated entity's Security Official
review and document the implementation and effectiveness of the
compensating controls during any period in which such compensating
controls are in use to continue securing ePHI and relevant electronic
[[Page 971]]
information systems. While regulated entities should review deployed
compensating controls on a routine basis, the Department proposes to
require a regulated entity to periodically review the implementation
and effectiveness of compensating controls to ensure the continued
protection of ePHI.\746\ For example, if a regulated entity's plan to
migrate ePHI from hardware that does not support encryption changes
such that the use of the unencrypted hardware continues for a longer
period of time, the regulated entity should review implemented
compensating controls to ensure ongoing effectiveness and whether new
compensating controls should be deployed. We propose to require the
designated Security Office conduct such review at least once every 12
months or in response to environmental or operational changes,
whichever is more frequent. Additionally, the Department proposes to
require that the review be documented in writing and signed. If the
regulated entity's Security Official review determines that certain
compensating controls are no longer effective, the Department expects
that the regulated entity would adopt new compensating controls that
are effective to continue to meet the applicable exception. For
example, a regulated entity would be expected to update any
compensating controls for use of an FDA-authorized medical device when
and as instructed by the manufacturer of the device.
---------------------------------------------------------------------------
\746\ The Department does not propose to require that the
periodic review include a review of whether the conditions of the
exception continue to apply because, when the conditions qualifying
for an exception change such that an exception no longer applies, a
regulated entity would be expected to resume compliance with the
standard for encryption and decryption and the associated
implementation specifications without exception.
---------------------------------------------------------------------------
We also propose to add an implementation specification for
maintenance at proposed 45 CFR 164.312(b)(5). Under this proposal, a
regulated entity would be expressly required to review and test the
effectiveness of the technical controls required by the standard for
encryption at least once every 12 months or in response to
environmental or operational changes, whichever is more frequent, and
modify as reasonable and appropriate. This proposal is consistent with
others in this NPRM that would require regulated entities to maintain
specified administrative, physical, and technical safeguards.
d. Section 164.312(c)(1)--Standard: Configuration Management
The Department believes that the failure to configure technical
controls appropriately and to establish and maintain secure baselines
for relevant electronic information systems and technology assets in
its relevant electronic information systems presents an opportunity for
cyberattack and compromise of ePHI.\747\ Accordingly, we propose to add
a standard for configuration management at proposed 45 CFR
164.312(c)(1). The proposed standard would require a regulated entity
to establish and deploy technical controls for securing relevant
electronic information systems and technology assets in its relevant
electronic information systems, including workstations, in a consistent
manner. Under this proposal, a regulated entity also would be required
to establish a baseline (i.e., minimum) level of security for each
relevant electronic information system and technology asset in its
relevant electronic information systems and to maintain such
information systems and technology assets according to those secure
baselines. Consistent with our proposals regarding risk analysis and
risk management planning, the Department intends for a regulated entity
to establish its security baseline and to maintain that baseline even
when technology changes. For example, a regulated entity that uses
software to access ePHI would be required to update the software with
patches as reasonable and appropriate. But where a developer ceases to
support a software, it would be reasonable and appropriate for the
regulated entity to take steps to either replace it or to otherwise
ensure that its level of security remains consistent with the regulated
entity's established baseline. Under this proposal, if finalized, the
Department would expect a regulated entity to continually monitor its
relevant electronic information systems and technology assets in its
relevant electronic information systems to ensure that the secure
baselines established by the regulated entity are maintained and take
appropriate actions when a relevant electronic information system or
technology asset in a relevant electronic information system fails to
meet the established baselines. A regulated entity's secure baselines
would be determined based on its risk analysis and use of security
settings that are consistent across its relevant electronic information
systems and technology assets in its relevant electronic information
systems. For example, the risk analysis may determine that a
manufacturer's default settings for a particular technology asset are
insufficient. Accordingly, the regulated entity may establish the
baseline for settings that should be applied to the particular asset
and similar technologies across the regulated entity's enterprise. This
proposed standard aligns with the Department's enhanced CPG for
Configuration Management, which calls for regulated entities to define
secure device and system settings. It also aligns with the enhanced CPG
for Detect and Respond to Relevant Threats and Tactics, Techniques, and
Procedures by calling for regulated entities to include malware
protection in their security baseline to detect threats and protect
electronic information systems.\748\ Additionally, the proposed
standard also aligns with the Department's essential CPG for Email
Security, which addresses the reduction of risks from email-based
threats.\749\
---------------------------------------------------------------------------
\747\ ``Defending Against Common Cyber-Attacks,'' supra note
396; see also ``HIPAA and Cybersecurity Authentication,'' supra note
368.
\748\ ``Cybersecurity Performance Goals,'' supra note 18.
\749\ Id.
---------------------------------------------------------------------------
The Department proposes five implementation specifications for the
proposed standard for configuration management.\750\ Under the proposed
implementation specification for anti-malware protection at proposed 45
CFR 164.312(c)(2)(i), a regulated entity would be required to deploy
technology assets and/or technical controls that protect all of the
technology assets in its relevant electronic information systems
against malicious software, such as viruses and ransomware. Anti-
malware software, especially when used in combination with other
technical controls such as intrusion detection/prevention solutions,
can also help prevent, detect, and contain cyberattacks.\751\ This
protection would be applied to all of a regulated entity's technology
assets in its relevant electronic information systems. When determining
how to fulfill this proposed obligation, regulated entities may
consider deploying tools such as anti-malware and endpoint detection
and response (EDR) solutions. Anti-malware tools generally scan a
regulated entity's electronic information systems to
[[Page 972]]
identify malicious software.\752\ Such tools may also quarantine
malicious software if identified. As explained by the Office of
Management and Budget, ``EDR combines real-time continuous monitoring
and collection of endpoint data [. . .] with rules-based automated
response and analysis capabilities.'' \753\
---------------------------------------------------------------------------
\750\ See proposed 45 CFR 164.312(c)(2).
\751\ ``What Happened to My Data?: Update on Preventing,
Mitigating and Responding to Ransomware,'' Cybersecurity Newsletter,
Office for Civil Rights, U.S. Department of Health and Human
Services (Dec. 2019), https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-fall-2019/index.html.
\752\ See ``Understanding Anti-Virus Software,'' Cybersecurity &
Infrastructure Security Agency, U.S. Dept. of Homeland Security
(June 30, 2009, rev. Sept. 27, 2019), https://www.cisa.gov/news-events/news/understanding-anti-virus-software.
\753\ ``Improving Detection of Cybersecurity Vulnerabilities and
Incidents on Federal Government Systems through Endpoint Detection
and Response,'' M-22-01, Office of Management and Budget, Executive
Office of the President, p. 1 (Oct. 8, 2021), https://www.whitehouse.gov/wp-content/uploads/2021/10/M-22-01.pdf.
---------------------------------------------------------------------------
We propose a new implementation specification for software removal
at proposed 45 CFR 164.312(c)(2)(ii) to require a regulated entity to
remove extraneous software from the regulated entity's relevant
electronic information systems. Software is extraneous if it is
unnecessary for the regulated entity's operations. It can be a target
for attack, and older applications may no longer be supported with
patches for new vulnerabilities.\754\ Removal of unnecessary software
reduces an avenue of attack. The Department is not proposing to specify
what would constitute necessary and unnecessary software. Rather, we
intend that the regulated entity would consider removal of unwanted or
unused software, for example, default software added by a computer
manufacturer or reseller where such software may open an avenue for
unnecessary risk because the regulated entity does not intend to use
it. Accordingly, the proposal would require a regulated entity to
consider all software on its relevant electronic information systems
and any potential avenue of risk and address the risk through software
removal where such software is unnecessary for the regulated entity's
operations.
---------------------------------------------------------------------------
\754\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
---------------------------------------------------------------------------
The proposed implementation specification for configuration at
proposed 45 CFR 164.312(c)(2)(iii) would require a regulated entity to
configure and secure operating systems and software in a manner
consistent with the regulated entity's risk analysis. Generally, a
regulated entity's risk analysis should guide its implementation of
appropriate technical controls to reduce the risk to ePHI.\755\
Requiring operating systems and software to be maintained in a secure
manner would reduce exploitable vulnerabilities.\756\ Often, known
vulnerabilities can be mitigated by applying vendor patches or
upgrading to a newer version.\757\
---------------------------------------------------------------------------
\755\ Id.
\756\ Id.
\757\ Id.
---------------------------------------------------------------------------
Under the proposed implementation specification for network ports
at proposed 45 CFR 164.312(c)(2)(iv), a regulated entity would be
required to disable network ports in accordance with the regulated
entity's risk analysis.\758\ Successful ransomware deployment often
depends on the exploitation of technical vulnerabilities such as
unsecured ports.\759\ The proposal to require network ports to be
disabled in accordance with the risk analysis would reduce exploitable
vulnerabilities.\760\
---------------------------------------------------------------------------
\758\ See proposed 45 CFR 164.308(a)(2).
\759\ ``What Happened to My Data?: Update on Preventing,
Mitigating and Responding to Ransomware,'' supra note 751.
\760\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
---------------------------------------------------------------------------
Lastly, the proposed implementation specification for maintenance
at proposed 45 CFR 164.312(c)(2)(v) would expressly require a regulated
entity to review and test the effectiveness of the technical controls
required by the other implementation specifications associated with the
standard for configuration management at least once every 12 months or
in response to environmental or operational changes, whichever is more
frequent, and modify as reasonable and appropriate.
e. Section 164.312(d)(1)--Standard: Audit Trail and System Log Controls
Audit controls are crucial technical safeguards that are useful for
recording and examining activity in electronic information systems,
especially when determining whether a security violation occurred.\761\
A regulated entity must consider its risk analysis and organizational
factors, such as current technical infrastructure, hardware, and
software security capabilities, to determine reasonable and appropriate
audit controls.\762\ However, based on OCR's enforcement experience, we
believe that regulated entities' understanding of and compliance with
this standard could be improved by providing more specificity.
---------------------------------------------------------------------------
\761\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 7.
\762\ Id.
---------------------------------------------------------------------------
Accordingly, the Department proposes to redesignate the standard
for audit controls at 45 CFR 164.312(b) as proposed 45 CFR
164.312(d)(1), rename it as the standard for audit trail and system log
controls, and to add a paragraph heading to clarify the organization of
the regulatory text. We also propose to modify it to require a
regulated entity to deploy either or both technology assets and
technical controls that record and identify activity in the regulated
entity's relevant electronic information systems. The proposal would
replace ``procedural mechanisms'' with ``technical controls,'' to match
the general focus on technical controls in 45 CFR 164.312 and would
recognize that a regulated entity may be able to meet the requirements
of the standard by deploying either or both technology assets (e.g.,
software) or technical controls. Under the proposal, a regulated entity
would be required to collect sufficient information to understand what
a specific activity in its relevant electronic information systems is,
such that the regulated entity would be better able to address activity
that presents a risk to the confidentiality, integrity, or availability
of ePHI. For example, a regulated entity should understand that a given
activity in a relevant electronic information system is an attempt to
access a portable workstation without authorization. The proposal also
would modify the limitation on the regulated entity's obligation to
record and identify activity in its relevant electronic information
systems. Thus, the proposal would require a regulated entity to record
and identify any activity that could present a risk to ePHI, meaning
activity in all of its relevant electronic information systems, not
only in its electronic information systems that create, receive,
maintain, or transmit ePHI. In so doing, the Department would also
require a regulated entity to record and identify activity in its
electronic information systems that may affect the confidentiality,
integrity, or availability of ePHI. This redesignated standard, as
proposed, aligns more closely with the Department's enhanced CPG for
Centralized Log Collection by addressing the deployment of technical
controls to record and identify activity in all electronic information
systems.\763\ Additionally, as an example, we note that adoption of
health IT certified through the ONC Health IT Certification Program may
contribute to a regulated entity's compliance with the proposed
standard for audit trail and system log controls where such health IT
meets the criteria for auditing actions on health information and
recording actions related to electronic health information and audit
log status.\764\
---------------------------------------------------------------------------
\763\ ``Cybersecurity Performance Goals,'' supra note 18.
\764\ The criterion for auditing actions on health information
requires adoption of health IT that has the technical capability to
record actions related to electronic health information; restrict
the ability for auditing to be disabled to a limited set of users,
if the technology permits; detect whether an audit log has been
altered; and not allow actions recorded related to electronic health
information to be changed, overwritten, or deleted by technology.
See 45 CFR 170.315(d)(10); see 45 CFR 170.315(d)(2); see also 45 CFR
170.210(e).
---------------------------------------------------------------------------
[[Page 973]]
The Department proposes four implementation specifications under
this proposed standard that are intended to improve the effectiveness
of audit controls deployed by a regulated entity. The proposed
implementation specification for monitoring and identifying activity at
proposed 45 CFR 164.312(d)(2)(i) would require a regulated entity to
deploy technology assets and/or technical controls that monitor in
real-time (i.e., contemporaneously) all activity occurring in a
regulated entity's relevant electronic information systems and identify
indications of unauthorized persons and unauthorized activity, as
determined by the regulated entity's risk analysis. As proposed, the
technology assets and/or technical controls also would be required to
alert workforce members of such indications in accordance with the
regulated entity's policies and procedures for information system
activity review at proposed 45 CFR 164.308(a)(7). Unauthorized activity
may include actions by technology assets or persons that have not been
authorized to access the regulated entity's ePHI or relevant electronic
information systems. It may also include actions by authorized users or
technology assets that are inconsistent with the regulated entity's
policies and procedures for information access management at proposed
45 CFR 164.308(a)(10). The Department proposes that monitoring be
continual and conducted in real-time because asynchronous review would
allow for the compromise of ePHI for the period of time between the
unauthorized activity and its discovery. OCR's enforcement experience
has shown that some regulated entities are potentially failing to
implement appropriate audit controls or to review information system
activity in a timely manner, which may have contributed to a reportable
breach.\765\
---------------------------------------------------------------------------
\765\ See, e.g., ``Montefiore Medical Center,'' supra note 248.
---------------------------------------------------------------------------
A regulated entity would be required, under the proposed
implementation specification for recording activity at proposed 45 CFR
164.312(d)(2)(ii), to deploy technology assets and/or technical
controls that record in real-time all activity in the regulated
entity's relevant electronic information systems.\766\ While technical
assets and/or technical controls deployed in accordance with proposed
45 CFR 164.312(d)(2)(i) would monitor activity in its relevant
electronic information systems, recording such activity would enable a
regulated entity to assess any activity to better understand the
activity's effects. The proposed implementation specification at
proposed 45 CFR 164.312(d)(2)(iii) would require a regulated entity to
deploy technology assets and/or technical controls to retain records of
all activity in its relevant electronic information systems as
determined by the regulated entity's policies and procedures for
information system activity review at 45 CFR 164.308(a)(7)(ii)(A). The
proposed implementation specification for scope of activity at proposed
45 CFR 164.312(d)(2)(iv) would clarify what would constitute activity
to be monitored and recorded in the regulated entity's relevant
electronic information systems as required by the proposed
implementation specifications at proposed 45 CFR 164.312(d)(2)(i) and
(ii). Specifically, the Department proposes that such activities would
include, but would not be limited to, creating, accessing, receiving,
transmitting, modifying, copying, or deleting ePHI; and creating,
accessing, receiving, transmitting, modifying, copying, or deleting
relevant electronic information systems and the information (i.e., not
only ePHI) therein.
---------------------------------------------------------------------------
\766\ See proposed 45 CFR 164.308(a)(2).
---------------------------------------------------------------------------
We also propose to add an implementation specification for
maintenance at proposed 45 CFR 164.312(d)(2)(iv). Under this proposal,
a regulated entity would be expressly required to review and test the
effectiveness of the technology assets and/or technical controls
required by the respective implementation specifications of this
section at least once every 12 months or in response to environmental
or operational changes, whichever is more frequent, and modify as
reasonable and appropriate.
f. Section 164.312(e)--Standard: Integrity
Improper alteration or destruction of ePHI, even unintentionally,
can result in clinical quality problems, including patient safety
issues, for a covered entity.\767\ Workforce members or business
associates may make accidental or intentional changes that improperly
alter or destroy ePHI.\768\ Data can also be altered or destroyed
without human intervention, such as by electronic media errors or
failures.\769\ It is important to protect ePHI from being compromised,
regardless of the source.\770\
---------------------------------------------------------------------------
\767\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 8.
\768\ Id.
\769\ Id.
\770\ Id.
---------------------------------------------------------------------------
The current standard for integrity at 45 CFR 164.312(c)(1) requires
implementation of policies and procedures, rather than actual
deployment of technical controls, to ensure integrity of ePHI. To
improve the effectiveness of this standard, the Department proposes to
redesignate it as proposed 45 CFR 164.312(e) and modify it for clarity.
Under the proposal, a regulated entity would be required to deploy
technical controls to protect ePHI from improper alteration or
destruction when at rest and in transit and to review and test the
effectiveness of such technical controls at least once every 12 months
or in response to environmental or operational changes, whichever is
more frequent, and modify as reasonable and appropriate. For example,
the adoption of health IT that is certified through the ONC Health IT
Certification Program as having the technical capability to verify that
the electronically exchanged health information contained within the
health IT has not been altered, using a hashing algorithm that meets
certain requirements, may contribute to a regulated entity's compliance
with the proposed standard for integrity.\771\ The Department proposes
to remove the implementation specification at 45 CFR 164.312(c)(2)
because technical controls to corroborate that ePHI has not been
altered or destroyed in an unauthorized manner are commonly built into
hardware and protocols today. Thus, it is unnecessary to require a
regulated entity to specifically deploy such controls.
---------------------------------------------------------------------------
\771\ 45 CFR 170.315(d)(8).
---------------------------------------------------------------------------
g. Section 164.312(f)(1)--Standard: Authentication
Authentication ensures that a person is in fact who they claim to
be before being allowed access to ePHI by providing proof of
identity.\772\ The Department proposes to redesignate the standard for
person or entity authentication at 45 CFR 164.312(d) as 45 CFR
164.312(f)(1) to rename it ``Authentication'' to reflect its broad
purpose, and to add a paragraph heading to clarify the organization of
the regulatory text. Additionally, consistent with our proposals to
define
[[Page 974]]
``implement'' and ``deploy,'' we propose to replace the requirement for
a regulated entity to implement procedures with a requirement to deploy
technical controls. Also, consistent with our proposals to clarify that
a regulated entity's obligations to ensure the confidentiality,
integrity, and availability extend to all of its relevant electronic
information systems, we propose to clarify that the regulated entity is
to deploy technical controls to verify that a person seeking access to
the regulated entity's relevant electronic information systems is the
one claimed. The Department also proposes to modify the existing
standard to clarify that a regulated entity would be required to deploy
technical controls to verify that a technology asset seeking access to
the regulated entity's relevant electronic information systems is the
one claimed. Thus, the proposed standard for authentication would
require a regulated entity to deploy technical controls to verify that
a person or technology asset seeking access to ePHI and/or the
regulated entity's relevant electronic information systems is, in fact,
the person or technology asset that the person or asset claims to be.
We also propose to remove the reference to an entity because entity is
included within the definition of person.
---------------------------------------------------------------------------
\772\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 9.
---------------------------------------------------------------------------
The Department proposes four implementation specifications under
this standard. Consistent with NCVHS' recommendation to eliminate the
use of default passwords, the proposed implementation specification for
information access management policies at proposed 45 CFR
164.312(f)(2)(i) would require a regulated entity to deploy technical
controls in accordance with its information access management policies
and procedures, including technical controls that require users to
adopt unique passwords.\773\ Among other things, this proposal would
ensure that regulated entities change default passwords. Such unique
passwords would be required to be consistent with current
recommendations of authoritative sources. The Department does not
propose to define authoritative sources and defers to best practices
for setting and maintaining passwords of sufficient strength to ensure
the confidentiality, integrity, and availability of ePHI. Under this
proposal, a regulated entity would need to require its workforce
members to change any default passwords to unique passwords that are
consistent with current authoritative source recommendations for unique
passwords, as well as prevent the sharing of passwords among workforce
members. Default passwords, typically factory-set passwords, may be
discovered in common product documentation and used by attackers to
gain access to relevant electronic information systems.\774\ Thus, the
Department believes that it is crucial for the security of ePHI that a
regulated entity eliminate the use of default passwords.
---------------------------------------------------------------------------
\773\ Letter from NCVHS Chair Jacki Monson (2022), supra note
123, p. 6.
\774\ ``Risks of Default Passwords on the internet,''
Cybersecurity & Infrastructure Security Agency, U.S. Department of
Homeland Security (Oct. 7, 2016), https://www.cisa.gov/news-events/alerts/2013/06/24/risks-default-passwords-internet.
---------------------------------------------------------------------------
In addition to proposing the elimination of default passwords, the
Department proposes a specific requirement for a regulated entity to
deploy MFA in the implementation specification for MFA at proposed 45
CFR 164.312(f)(2)(ii). We propose to expressly require MFA, as
recommended by NCVHS, because it increases security by ensuring that a
compromise of a single credential does not allow access to unauthorized
users.\775\ MFA is an effective way to reduce the risk of brute force
attacks and to increase the cost of such attack, making such an attack
less appealing to intruders.\776\ Further, deployment of MFA aligns
with the Department's essential CPGs for Email Security and Multifactor
Authentication because use of MFA would be applicable to email access
and protect assets connected to the internet.\777\ Accordingly,
proposed 45 CFR 164.312(f)(2)(ii)(A) would require a regulated entity
to deploy MFA to all technology assets in its relevant electronic
information systems to verify that the person seeking access to its
relevant electronic information system is the user that the person
claims to be. A regulated entity should deploy MFA to all technology
assets in its relevant electronic information systems in a manner
consistent with its risk analysis. MFA allows for the use of different
categories of factors as described earlier. A decision by a regulated
entity to use specific factors during specific circumstances where MFA
is deployed will be dependent upon the risks to ePHI identified by the
regulated entity and the ability of technology to use such factors to
authenticate specific users. For example, certain behavioral
characteristics may not satisfy current standards for MFA; however, the
Department anticipates that it may be reasonable and appropriate in the
future for a regulated entity to adopt a solution where users provide
such characteristics as one of the factors. Additionally, a regulated
entity may identify varying levels of risk posed by its technology
assets and elect to deploy MFA in different ways to address the risk
posed by each asset. For example, consistent with its risk analysis, a
regulated entity may choose to deploy a single sign-on (SSO)
authentication solution using MFA to allow users to access multiple
local applications, while also requiring users to authenticate using
MFA to access certain cloud-based services.
---------------------------------------------------------------------------
\775\ ``Multi-Factor Authentication,'' Cybersecurity &
Infrastructure Security Agency, U.S. Department of Homeland Security
(Jan. 5, 2022), https://www.cisa.gov/sites/default/files/publications/MFA-Fact-Sheet-Jan22-508.pdf; Letter from NCVHS Chair
Jacki Monson (2022), supra note 123, pp. 7-8.
\776\ Letter from NCVHS Chair Jacki Monson (2022), supra note
123, pp. 7-8.
\777\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
This proposed implementation specification generally is consistent
with ASTP/ONC's ``Health Data, Technology, and Interoperability:
Patient Engagement, Information Sharing, and Public Health
Interoperability'' (HTI-2) NPRM's proposed revisions to the MFA
criterion requiring certified health IT to support authentication,
through multiple elements, of the user's identity, according to today's
standards such as those recommended by NIST, and enable user to
configure, enable, and disable the MFA capabilities.\778\ Adoption of
health IT that is certified through the ONC Health IT Certification
Program as meeting the proposed MFA criterion, should the proposal be
finalized, may contribute to a regulated entity's compliance with the
proposed implementation specification for MFA in this NPRM.
---------------------------------------------------------------------------
\778\ See 89 FR 63498, 63574, 63506, 63528 (Aug. 5, 2024)
(proposed 45 CFR 170.315(d)(13)(ii) of ASTP/ONC's HTI-2 NPRM).
---------------------------------------------------------------------------
Under proposed 45 CFR 164.312(f)(2)(ii)(B), a regulated entity
would be required to deploy MFA for any action that would change a
user's privileges to the regulated entity's relevant electronic
information systems in a manner that would alter the user's ability to
affect the confidentiality, integrity, or availability of ePHI. These
modified privileges may provide a user with a level of access
inconsistent with a regulated entity's policies and procedures and
increase the risk to ePHI by affording a user who does not need to have
access to certain systems or information the opportunity to remove
security measures deployed to protect ePHI. Because a user may affect
the confidentiality, integrity, or availability of ePHI by accessing a
relevant electronic information system, a regulated entity would be
expected to
[[Page 975]]
deploy MFA for changed privileges in both types of systems.
Similar to the proposed standard for encryption, the Department
proposes three exceptions at proposed 45 CFR 164.312(f)(2)(iii) to the
proposed specific requirement to implement MFA. The first proposed
exception at proposed 45 CFR 164.312(f)(2)(iii)(A) would be for a
technology asset that does not support MFA but is currently in use by a
regulated entity. Because the requirements for authentication under the
existing Security Rule today do not expressly refer to MFA, a regulated
entity that is not using MFA to meet the requirement to authenticate
user identities may argue that it is in compliance with the
authentication standard without using MFA. The Department recognizes
that it may take some time for a regulated entity to adopt compliant
software or hardware, and thus we propose an exception where such
software or hardware does not support MFA. To meet this exception, a
regulated entity would be required to establish a written plan to
migrate ePHI to technology assets that supports MFA and to actually
migrate the ePHI to such technology assets in accordance with the
written plan. Accordingly, a regulated entity would be required to
establish the plan, implement the plan, and actually migrate ePHI to
technology assets that supports MFA within a reasonable and appropriate
period of time. For example, it would not be reasonable and appropriate
for a regulated entity to establish a plan to migrate to a new practice
management system that supports MFA and fail to take any steps to
perform the migration for an entire year. Applying the standard
flexibly and at scale, a reasonable and appropriate timeframe for a
system with 5,000 users may be different than one for a solo
practitioner; however, both entities would be expected to progress to
completion.
We recognize that emergencies or other occurrences may render it
infeasible for a regulated entity to use MFA, so we propose a second
exception for when MFA is infeasible during an emergency or other
occurrence that adversely affects the regulated entity's relevant
electronic information systems or the confidentiality, integrity, or
availability of ePHI.\779\ For the proposed exception to apply, a
regulated entity would be required to implement reasonable and
appropriate compensating controls in accordance with its contingency
plan \780\ and emergency access procedures.\781\ For example, if an
optical scanner used by a regulated entity as one of the required
factors for MFA is rendered inoperable (e.g., is temporarily broken or
adversely affected by a cyberattack), a compensating control may be to
temporarily allow users to log in with their user name and a unique
password, rather than with a PIN and retinal scan. The Department would
make this proposed exception applicable only for the limited period of
time in which MFA is infeasible for the regulated entity during the
emergency or other occurrence, regardless of whether the emergency or
other occurrence continues.
---------------------------------------------------------------------------
\779\ See proposed 45 CFR 164.312(f)(2)(iii)(B).
\780\ See proposed 45 CFR 164.308(a)(13).
\781\ See proposed 45 CFR 164.312(a)(2)(iii).
---------------------------------------------------------------------------
At proposed 45 CFR 164.312(f)(2)(iii)(C), we propose three
exceptions that would be for a technology asset in use that is a device
within the meaning of section 201(h) of the Food, Drug, and Cosmetic
Act that has been authorized for marketing by the FDA. The first would
be for a device authorized by the FDA for marketing pursuant to a
submission received before March 29, 2023, while the second would be
for a device authorized by the FDA for marketing pursuant to a
submission received on or after March 29, 2023, that is no longer
supported by its manufacturer. In both cases, the exception would only
apply where, the regulated entity has deployed any updates or patches
required or recommended by the manufacturer of the device. Similar to
our proposal for exceptions to encryption at proposed 45 CFR
164.312(b)(3)(iv)(A) and (B), we recognize that some regulated entities
may incur costs of replacing legacy devices because of the limitations
on the proposed exception to MFA where a device was submitted to the
FDA for authorization before March 29, 2023 or a device submitted for
authorization on or after that date that is no longer supported by its
manufacturer.\782\ However, as discussed above, such devices can pose
significant risks to the confidentiality, integrity, and availability
of ePHI.\783\ By limiting these exceptions to devices that have been
updated and/or patched while they were supported by their manufacturer,
we believe that this proposal would balance the interest in encouraging
regulated entities to dispense with legacy devices with the cost of
replacing such devices. Additionally, the Department believes that
regulated entities should already have plans to replace legacy devices
that cannot be made cybersecure because of their existing Security Rule
obligations. As discussed above, we also recognize that at some point,
most, if not all, devices will likely become legacy devices and that
there may be legitimate reasons not to immediately replace them when
the manufacturer ceases to provide support. In such cases, it will
continue to be important for regulated entities to plan for how to
address their ongoing Security Rule obligations.
---------------------------------------------------------------------------
\782\ See ``Next Steps Toward Managing Legacy Medical Device
Cybersecurity Risks,'' supra note 742; ``Principles and Practices
for the Cybersecurity of Legacy Medical Devices,'' supra note 742,
p. 8.
\783\ ``Cybersecurity,'' supra note 743.
---------------------------------------------------------------------------
The third proposed exception to MFA at 45 CFR
164.312(f)(2)(iii)(C)(3) for devices authorized by the FDA for
marketing would be available for those devices authorized for marketing
by the FDA pursuant to a submission received on or after March 29,
2023, where they are supported by their manufacturer. We understand
that the FDA considers security during the review of medical device
marketing submissions and works with device manufacturers to ensure
that appropriate cybersecurity protections are built into such devices,
pursuant to FDA's authority under the Consolidated Appropriations Act,
2023.\784\ Thus, we do not believe it would be necessary or appropriate
for the Security Rule to require MFA for an FDA-authorized medical
device that has been authorized by FDA for marketing pursuant to a
submission received on or after March 29, 2023, where the device
continues to be supported by its manufacturer. However, these devices
may continue to be used by a regulated entity when they are no longer
supported, consistent with the proposed exception for legacy devices
that were approved pursuant to a submission received on or after March
29, 2023, as described above.
---------------------------------------------------------------------------
\784\ See sec. 3305 of Public Law 117-328, 126 Stat. 5832 (Dec.
29, 2022) (codified at 21 U.S.C. 360n-2); see also ``Cybersecurity
in Medical Devices Frequently Asked Questions (FAQs),'' supra note
744.
---------------------------------------------------------------------------
Where a proposed exception would apply to the proposed MFA
requirement, the Department proposes to require that a regulated entity
implement alternative measures and compensating controls.\785\
Specifically, when a regulated entity seeks to comply with the Security
Rule by meeting one of the proposed exceptions to the proposed MFA
requirement, the Department proposes to require a regulated entity to
document both the existence of the criteria demonstrating that the
proposed exception would apply and the rationale for why the proposed
exception would apply.
[[Page 976]]
Additionally, the proposal would require a regulated entity to
implement reasonable and appropriate compensating controls, as
described at proposed paragraph (f)(2)(iv)(B).
---------------------------------------------------------------------------
\785\ Proposed 45 CFR 164.312(f)(2)(iv)(A).
---------------------------------------------------------------------------
The proposed requirements for reasonable and appropriate
compensating controls are explained under proposed 45 CFR
164.312(f)(2)(iv)(B). Compensating controls are implemented in the
place of MFA to protect ePHI.\786\ The Department does not propose to
require that compensating controls be technical controls. Rather, a
regulated entity should consider the nature of the exception, operating
environment, and other appropriate circumstances to determine what
controls are reasonable and appropriate and implement compensating
controls effective for those circumstances. For example, if a software
program does not support MFA, deploying a firewall or increasing the
sensitivity of an existing firewall protecting that software may in
some circumstances constitute a reasonable and appropriate compensating
control.\787\ In some instances, physical safeguards may serve as
reasonable and appropriate compensating controls. For example, limiting
access to certain components of a relevant electronic information
system to workforce members who meet certain requirements may be a
reasonable and appropriate compensating control under some
circumstances. In most cases, it would be reasonable and appropriate
for a regulated entity to implement multiple compensating controls to
ensure that the affected electronic information system is secured.
---------------------------------------------------------------------------
\786\ ``Glossary of Key Information Security Terms,'' supra note
745.
\787\ ``Securing Your Legacy [System Security],'' supra note
494.
---------------------------------------------------------------------------
The Department proposes at proposed 45 CFR 164.312(f)(2)(iv)(B)(1)
that, to comply with an exception at paragraph (f)(2)(iii)(A) or (B) or
(f)(2)(iii)(C)(1) or (2), the regulated entity would be required to
secure the relevant electronic information system with reasonable and
appropriate compensating controls that have been reviewed, approved,
and signed by the regulated entity's Security Official. Because
exceptions are a departure from the designed Security Rule framework,
the Department intends to ensure appropriate review by the Security
Official of controls selected by the regulated entity to compensate for
the absence of MFA. Merely because a regulated entity's Security
Official has reviewed, approved, and signed off on compensating
controls does not mean that those controls are effective. The regulated
entity would also be required to give due consideration to the
circumstances surrounding the exception and implement compensating
controls effective for those specific circumstances.
With respect to the exception at proposed 45 CFR
164.312(f)(2)(iii)(C)(3), the Department proposes at proposed 45 CFR
164.312(f)(2)(iv)(B)(2) to presume that a regulated entity had
implemented reasonable and appropriate compensating controls where the
regulated entity has implemented the security measures prescribed and
as instructed by the FDA-authorized label for the device. The proposed
language recognizes that while the device's label may not specifically
require deployment of an MFA solution, it may provide for a specific
compensating control and the manner in which that control is to be
implemented. This would include any updates, such as patches,
recommended or required by the manufacturer of the device. While not
required, a regulated entity would be permitted to implement additional
alternative security measures and compensating controls in accordance
with best practices and/or its risk analysis.
Additionally, the Department proposes at 45 CFR
164.312(f)(2)(iv)(B)(3) that during any period in which compensating
controls are in use, the regulated entity's Security Official would be
required to review the effectiveness of the compensating controls at
securing its relevant electronic information systems. While regulated
entities should review implemented compensating controls on a routine
basis, the Department intends for a regulated entity to periodically
review the implementation and effectiveness of implemented compensating
controls to ensure the continued protection of ePHI.\788\ For example,
if a regulated entity's plan to migrate ePHI from hardware that does
not support MFA changes such that the use of the non-MFA hardware
continues for a longer period of time, the regulated entity should
review implemented compensating controls to ensure ongoing
effectiveness and whether new compensating controls should be
implemented. We are proposing to require that the review be conducted
at least once every 12 months or in response to an environmental or
operational change, whichever is more frequent, and that the review be
documented. Additionally, the Department proposes to require that the
review be documented. If the regulated entity's Security Official
review determines that certain compensating controls are no longer
effective, the Department would expect the regulated entity to adopt
other compensating controls that are effective to continue to meet the
applicable proposed exception.
---------------------------------------------------------------------------
\788\ The Department does not propose that the periodic review
include a review that the conditions of the exception continue to
apply because a regulated entity would be expected to resume
compliance with the implementation specification of multi-factor
authentication when such exception no longer applies.
---------------------------------------------------------------------------
As an example of how proposed 45 CFR 164.312(f)(2)(iii) would
operate in concert with proposed 45 CFR 164.312(f)(2)(iv), a regulated
entity experiencing an emergency that adversely affects a relevant
electronic information system and renders MFA infeasible would be
required to document the following:
The regulated entity has experienced an emergency that has
adversely affected a relevant electronic information system, including
the nature of the emergency and the specific circumstances that
adversely affected the specific electronic information system.
MFA has been rendered infeasible with respect to the
specific relevant electronic information system adversely affected by
the emergency.
The regulated entity has put in place reasonable and
appropriate compensating controls in accordance with the regulated
entity's emergency access procedures and contingency plan.
As part of its documentation, a regulated entity would need to
include the controls that have been deployed, a record of the fact that
the compensating controls are in use, and a record indicating that the
compensating controls have been reviewed and approved by the regulated
entity's Security Official. Proposed 45 CFR 164.312(f)(2)(iv)(B)(3)
would require the Security Official to review and document the
effectiveness of the compensating controls at least once every 12
months or in response to an environmental or operational change,
whichever is more frequent. A determination regarding the effectiveness
of the technical controls would be based on their ability to secure the
regulated entity's ePHI and its relevant electronic information
systems.
Last, we propose to add an implementation specification for
maintenance at proposed 45 CFR 164.312(f)(2)(v). Under this proposal, a
regulated entity would be expressly required to review and test the
effectiveness of the technical controls required by this standard at
least once every 12 months or in response to
[[Page 977]]
environmental or operational changes, whichever is more frequent, and
modify as reasonable and appropriate.
h. Section 164.312(g)--Standard: Transmission Security
Transmission security protects against the interception of ePHI in
the communications networks used by regulated entities to transmit
ePHI.\789\ The Department proposes to redesignate the standard for
transmission security as proposed 45 CFR 164.312(g) and to modify the
standard consistent with other proposals made elsewhere in this NPRM,
as described below. Specifically, we propose to clarify the existing
standard by requiring a regulated entity to deploy technical controls
to guard against unauthorized access to ePHI in transmission over an
electronic communications network. For example, adoption of health IT
that is certified through the ONC Health IT Certification Program as
having the technical capability to establish a trusted connection using
encrypted and integrity message protection or a trusted connection for
transport and deploying such capability may contribute to a regulated
entity's compliance with the proposed standard for transmission
security.\790\ These proposed changes are consistent with the
Department's proposals to replace ``implement'' with ``deploy'' in the
context of technical safeguards to differentiate between implementation
of a written policy or procedure and deployment of technical controls.
---------------------------------------------------------------------------
\789\ ``Glossary of Key Information Security Terms,'' supra note
745.
\790\ See 45 CFR 170.315(d)(9).
---------------------------------------------------------------------------
Consistent with our proposals to require that regulated entities
maintain their technical controls, we also propose to require a
regulated entity to review and test the effectiveness of its technical
controls for guarding against unauthorized access to ePHI that is being
transmitted over an electronic communications network. We propose that
such review and testing occur at least once every 12 months or in
response to environmental or operational changes, whichever is more
frequent, and modify such technical controls as reasonable and
appropriate.
The Department also proposes to remove the implementation
specification for integrity controls at 45 CFR 164.312(e)(2)(i) because
these requirements are incorporated in the standard for integrity at
proposed 45 CFR 164.312(e), discussed above. A regulated entity would
continue to be required to review the current methods used to transmit
ePHI and then deploy appropriate solutions to protect ePHI from
improper alteration or destruction.\791\
---------------------------------------------------------------------------
\791\ ``Security Standards: Technical Safeguards,'' supra note
343, p. 10-11.
---------------------------------------------------------------------------
i. Section 164.312(h)(1)--Standard: Vulnerability Management
Hackers can penetrate a regulated entity's network and gain access
to ePHI by exploiting publicly known vulnerabilities.\792\ Exploitable
vulnerabilities can exist in many parts of the technology
infrastructure of a regulated entity's relevant electronic information
systems (e.g., server, desktop, and mobile device operating systems;
application, database, and web software; router, firewall, and other
device firmware).\793\ A regulated entity can identify technical
vulnerabilities in multiple, complementary ways, including:
---------------------------------------------------------------------------
\792\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
\793\ Id.
---------------------------------------------------------------------------
Subscribing to CISA alerts \794\ and bulletins.\795\
---------------------------------------------------------------------------
\794\ See ``Cybersecurity Alerts & Advisories,'' Cybersecurity &
Infrastructure Security Agency, U.S. Department of Homeland
Security, https://www.cisa.gov/news-events/cybersecurity-advisories.
\795\ See ``Bulletins,'' Cybersecurity & Infrastructure Security
Agency, U.S. Department of Homeland Security, https://www.cisa.gov/news-events/bulletins.
---------------------------------------------------------------------------
Subscribing to alerts from the HHS Health Sector
Cybersecurity Coordination Center.\796\
---------------------------------------------------------------------------
\796\ See ``Health Sector Cybersecurity Coordination Center
(HC3),'' Office of the Chief Information Officer, U.S. Department of
Health and Human Services, https://www.hhs.gov/about/agencies/asa/ocio/hc3/index.html.
---------------------------------------------------------------------------
Participating in an information sharing and analysis
center (ISAC) or information sharing and analysis organization (ISAO).
Implementing a vulnerability management program that
includes using a vulnerability scanner to detect vulnerabilities such
as obsolete software and missing patches.
Periodically conducting penetration tests to identify
weaknesses that could be exploited by an attacker.
Additionally, CISA has compiled a database of free cybersecurity
services and tools, some provided directly by CISA and others provided
by private and public sector organizations.\797\ For example, public
and private critical infrastructure organizations may avail themselves
of CISA's Cyber Hygiene Services.\798\ These services are available at
no cost to such organizations and can help regulated entities reduce
their risk level, identify vulnerabilities that could otherwise go
unmanaged and increase the accuracy and effectiveness of their response
activities, among other benefits, putting them in a better place to
make risk-informed decisions. CISA's Cyber Hygiene Services include
both vulnerability scanning and web application scanning. CISA also has
compiled a specific suite of tools and services for high-risk
communities.\799\
---------------------------------------------------------------------------
\797\ ``Free Cybersecurity Services and Tools,'' supra note 313.
\798\ ``Cyber Hygiene Services,'' supra note 313.
\799\ ``Cybersecurity Resources for High-Risk Communities,''
supra note 313.
---------------------------------------------------------------------------
To address the potential for a bad actor to exploit publicly known
vulnerabilities, and consistent with NCVHS' recommendation, the
Department proposes to add a new standard for vulnerability management
at 45 CFR 164.312(h)(1).\800\ The proposed standard would require a
regulated entity to deploy technical controls to identify and address
technical vulnerabilities in the regulated entity's relevant electronic
information systems. The deployment of technical controls should be
consistent with the regulated entity's patch management policies and
procedures at proposed 45 CFR 164.308(a)(4). This proposed standard
aligns with the Department's enhanced CPGs for Cybersecurity Testing
and Third Party Vulnerability Disclosure by calling for regulated
entities to employ multiple processes to discover technical
vulnerabilities, including vulnerabilities in workstations and in
technology assets provided by vendors and service providers.\801\ For
example, a regulated entity should include a device owned by a person
other than the regulated entity (e.g., the medical device manufacturer)
in its vulnerability management activities where the device is deployed
on the regulated entity's network. The regulated entity should also
include all workstations (e.g., desktop computers, mobile devices) that
are part of its relevant electronic information systems in its
vulnerability management activities.
---------------------------------------------------------------------------
\800\ Letter from NCVHS Chair Jacki Monson (2022), supra note
123, p. 8-9.
\801\ ``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
To implement this proposed standard, we propose four implementation
specifications. Proposed 45 CFR 164.312(h)(2)(i)(A) would require a
regulated entity to conduct automated scans of the regulated entity's
relevant electronic information systems, including all of the
components of such relevant electronic information systems (e.g.,
workstations, private networks) to identify technical vulnerabilities.
Vulnerability scans detect vulnerabilities such as obsolete software
[[Page 978]]
and missing patches.\802\ Once identified, assessed, and prioritized,
appropriate measures need to be implemented to mitigate these
vulnerabilities (e.g., apply patches, harden systems, retire
equipment).\803\ Under the proposal, the scans would be required to be
conducted in accordance with the regulated entity's risk analysis under
proposed 45 CFR 164.308(a)(2) and no less frequently than once every
six months.
---------------------------------------------------------------------------
\802\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
\803\ Id.
---------------------------------------------------------------------------
Relatedly, proposed 45 CFR 164.312(h)(2)(i)(B) would add an
implementation specification for maintenance of the technology assets
that conduct the required automated vulnerability scans. Under this
proposal, a regulated entity would be expressly required to review and
test the effectiveness of the technology asset(s) that conducts the
automated vulnerability scans that would be required by the proposed
implementation specification at proposed 45 CFR 164.312(h)(2)(i)(A) at
least once every 12 months or in response to environmental or
operational changes, whichever is more frequent, and modify as
reasonable and appropriate.
Identification of a known vulnerability in a relevant electronic
information system or a component thereof is a necessary precursor for
a regulated entity to take action to mitigate the vulnerability. A 2019
study on vulnerability and patch management found that 48 percent of
respondents reported that their organizations had at least one breach
in the preceding two years. Of those, 60 percent said that the breaches
could have occurred because an available patch for a known
vulnerability had not been applied.\804\
---------------------------------------------------------------------------
\804\ This study is not specific to health care. ``Costs and
Consequences of Gaps in Vulnerability Response,'' ServiceNow and
Ponemon Institute, p. 3 (2019), https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/resource-center/analyst-report/ponemon-state-of-vulnerability-response.pdf.
---------------------------------------------------------------------------
Accordingly, the Department also proposes a new implementation
specification for monitoring at proposed 45 CFR 164.312(h)(2)(ii) to
require that a regulated entity monitor authoritative sources for known
vulnerabilities on an ongoing basis and take action to remediate
identified vulnerabilities in accordance with the regulated entity's
patch management program.\805\ The Department expects such monitoring
to be conducted on an ongoing basis and is not proposing to specify a
minimum time interval for reviewing sources. We are also not proposing
to prescribe the specific sources of known vulnerabilities because such
sources may change over time and the vulnerabilities for which
regulated entities may be monitoring may vary greatly among regulated
entities. We propose to require that the sources used must be
authoritative. Examples of authoritative sources of known
vulnerabilities would include NIST's National Vulnerability Database
\806\ and CISA's Known Exploited Vulnerabilities Catalog.\807\
---------------------------------------------------------------------------
\805\ See proposed 45 CFR 164.308(a)(4).
\806\ ``National Vulnerability Database,'' supra note 398.
\807\ ``Known Exploited Vulnerabilities Catalog,'' supra note
399.
---------------------------------------------------------------------------
The proposed implementation specification for penetration testing
at 45 CFR 164.312(h)(2)(iii) would require a regulated entity to
conduct periodic testing of the regulated entity's relevant electronic
information systems for vulnerabilities, commonly referred to as
penetration testing. Penetration tests identify vulnerabilities in the
security features of an application, system, or network by mimicking
real-world attacks \808\ and are an effective way to identify
weaknesses that could be exploited by an attacker.\809\ The proposal
would require such testing to be conducted by qualified person(s). We
propose to describe a qualified person as a person with appropriate
knowledge of and experience with generally accepted cybersecurity
principles and methods for ensuring the confidentiality, integrity, and
availability of ePHI. We believe that within the cybersecurity
industry, it is understood that a person who is qualified to conduct
such penetration testing is an individual who has a combination of one
or more qualifying credentials, skills, or experiences to perform
``ethical hacking'' or ``offensive security'' of information systems.
The proposal would require a regulated entity to conduct such testing
at least once every 12 months, or in accordance with the regulated
entity's risk analysis,\810\ whichever is more frequent.
---------------------------------------------------------------------------
\808\ ``Glossary of Key Information Security Terms,'' supra note
745.
\809\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
\810\ See proposed 45 CFR 164.308(a)(2).
---------------------------------------------------------------------------
Lastly, we are proposing a new implementation specification for
patch and update installation at 45 CFR 164.312(h)(2)(iv) to require a
regulated entity to configure and implement technical controls to
install software patches and critical updates in a timely manner in
accordance with the regulated entity's patch management program.\811\
The proposed standard for patch management, an administrative safeguard
discussed above, would require a regulated entity to establish and
implement written policies and procedures for applying patches and
updating relevant electronic information system configurations, while
this proposal would require the regulated entity to implement technical
controls to implement those written policies and procedures. In other
words, proposed 45 CFR 164.312(h)(2)(iv) addresses the technical
controls to effectuate a regulated entity's patch management plan.
Applying patches for technology assets, including workstations, is an
effective mechanism to mitigate known vulnerabilities and limit the
risk of exploitation.\812\ Although older applications or devices may
no longer be supported with patches for new vulnerabilities, regulated
entities still must take appropriate action if a newly discovered
vulnerability affects an older application or device. If an obsolete,
unsupported system cannot be upgraded or replaced, additional
safeguards should be implemented or existing safeguards enhanced to
mitigate known vulnerabilities until upgrade or replacement can occur
(e.g., increase access restrictions, remove or restrict network access,
disable unnecessary features or services).\813\ Deployment of such
technical controls would help to ensure that a regulated entity's
relevant electronic information systems are updated as quickly as
possible after a vulnerability has been identified and a patch
released.
---------------------------------------------------------------------------
\811\ See proposed 45 CFR 164.308(a)(5).
\812\ ``Defending Against Common Cyber-Attacks,'' supra note
396.
\813\ See ``Securing Your Legacy [System Security],'' supra note
494.
---------------------------------------------------------------------------
The proposed standard for patch management, discussed above, would
work in tandem with the proposed standard for vulnerability management
to ensure that regulated entities substantially reduce the risk to ePHI
from known vulnerabilities.\814\ Together, these proposals would
clarify that a regulated entity is required to affirmatively seek out
information about known vulnerabilities, assess the risks to the
confidentiality, integrity, and availability of ePHI, and implement
effective mechanisms through both policies and procedures and technical
controls to reduce the risk, as well the actual occurrence, of breaches
resulting from known vulnerabilities. For example, known
vulnerabilities should be readily identified by a regulated entity
through monitoring of
[[Page 979]]
authoritative sources for known vulnerabilities, such as those
referenced above, and remediating any identified vulnerabilities. When
a vulnerability is discovered, a regulated entity, through its patch
management program, should have in place a policy and procedure for
applying any available patches or implementing reasonable and
appropriate compensating controls if a patch is not available.
Remediation may be as simple as applying a vendor-offered software
patch or, in the case of software no longer supported by a vendor,
designing and implementing reasonable and appropriate compensating
controls to reduce the risk of the vulnerability. The policies and
procedures required by the proposed standard for patch management in
proposed 45 CFR 164.308(a)(4)(i) also would be implemented in part by
the proposed implementation specifications associated with the proposed
standard for vulnerability management. Those proposed implementation
specifications would require the deployment of technical controls to
ensure the patch management program is carried out, automated
vulnerability scans, and penetration testing, all of which may identify
when a patch or compensating control has not been put in place. The
Department envisions that the full implementation of all of the
proposed standards and implementation specifications would effectively
reduce the risk to ePHI.
---------------------------------------------------------------------------
\814\ See proposed 45 CFR 164.308(a)(5) and 164.312(h)(1).
---------------------------------------------------------------------------
j. Section 164.312(i)(1)--Standard: Data Backup and Recovery
The Security Rule requires regulated entities to regularly create
copies of ePHI to ensure that it can be restored in the event of a loss
or disruption.\815\ However, OCR's enforcement experience indicates
that regulated entities could benefit from a more specific standard.
Consistent with the proposed standard for contingency planning at 45
CFR 164.308(a)(13)(ii)(B), the Department proposes to add a standard
for a new technical safeguard for data backup and recovery. This new
standard would require a regulated entity to deploy technical controls
to create and maintain exact retrievable copies of ePHI. The proposed
changes would remove the existing implementation specification for this
activity from the physical safeguards section and place it within
technical safeguards. The Department also proposes to modify the
language of the existing requirement by removing the limitation that it
applies before moving equipment, so that it applies broadly and
comprehensively. Elevating data backup and recovery to a standard would
also increase the prominence of this requirement and highlight the
liability of regulated entities for creating the capacity to restore
systems after a data breach.
---------------------------------------------------------------------------
\815\ See ``Plan A . . . B . . . Contingency Plan!,'' supra note
606.
---------------------------------------------------------------------------
The Department proposes four new implementation specifications for
the data backup and recovery standard. The first, 45 CFR
164.312(i)(2)(i), would require a regulated entity to create copies of
ePHI in a manner that ensures that such copies are no more than 48
hours older than the ePHI maintained in the regulated entity's relevant
electronic information systems and in accordance with the policies and
procedures required by proposed 45 CFR 164.308(a)(13)(ii)(B). The
second, 45 CFR 164.312(i)(2)(ii), would require a regulated entity to
deploy technical controls that, in real-time, monitor, and alert
workforce members about, any failures and error conditions of the
backups required by the first implementation specification. The third,
45 CFR 164.312(i)(2)(iii), would require a regulated entity to deploy
technical controls that record the success, failure, and any error
conditions of backups required. The fourth, 45 CFR 164.312(i)(2)(iv),
would require a regulated entity to test the effectiveness of its
backups and document the results at least monthly. Specifically, a
regulated entity would be required to restore a representative sample
of backed up ePHI (after the ePHI is backed up as required by paragraph
(i)(2)(i)) and document the results of such test restorations at least
monthly. Such tests should include verifying regulated entity's ability
to access ePHI from a remote location.
These activities are included in NIST guidance for Security Rule
compliance,\816\ which directs regulated entities to consider the
following questions: Is the frequency of backups appropriate for the
environment? Are backup logs reviewed and data restoration tests
conducted to ensure the integrity of data backups? Is at least one copy
of the data backup stored offline to protect against corruption due to
ransomware or other similar attacks? The potential need for these
requirements also has been indicated through the rising number of
ransomware attacks and the high number of individuals affected in such
incidents. The Department believes these new implementation
specifications, if finalized, would provide additional instruction for
regulated entities about conducting data backups and enhance the
ability of regulated entities to avoid costly work stoppages and
interruptions in the delivery of health care when data becomes
unavailable because of a disaster, security incident, or other
emergency. We believe enhanced measures for data backup would reduce
the need to pay ransom to hackers to recover compromised data.
---------------------------------------------------------------------------
\816\ See ``Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource
Guide,'' supra note 461, p. 49.
---------------------------------------------------------------------------
k. Section 164.312(j)--Standard: Information Systems Backup and
Recovery
The Department also proposes to add a new standard for backup and
recovery of relevant electronic information systems at proposed 45 CFR
164.312(j). This proposed standard would require a regulated entity to
deploy technical controls to create and maintain backups of relevant
electronic information systems. It would also require a regulated
entity to review and test the effectiveness of such technical controls
at least once every six months or in response to environmental or
operational changes, whichever is more frequent, and modify them as
reasonable and appropriate. The Department would not require a
regulated entity to test every relevant electronic information system;
rather, the requirement to test the effectiveness of the controls would
permit a regulated entity to review the relevant log files and to test
a representative sample of the backup of its relevant electronic
information systems.
This proposed standard would reduce potential gaps in the data that
needs to be backed up and recovered, to ensure that regulated entities
address compliance across relevant electronic information systems. It
is crucial to a regulated entity's recovery from an emergency or other
occurrence, including a security incident, that adversely affects its
relevant electronic information systems to create and maintain backups
of such information systems that comprise the infrastructure that
maintains and supports the confidentiality, integrity, and availability
of ePHI. The Department would expect that the extent of this activity
would be affected by the size and complexity of the relevant electronic
information systems used by a regulated entity. It is also consistent
with NIST guidance, which directs regulated entities to consider
whether backups or images of operating systems, devices, software, and
configuration files necessary to support the
[[Page 980]]
confidentiality, integrity, and availability of ePHI.\817\
---------------------------------------------------------------------------
\817\ Id.
---------------------------------------------------------------------------
4. Request for Comment
The Department requests comments on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. Whether there are additional technical safeguards that the
Department should require regulated entities to implement.
b. Whether there are additional implementation specifications that
should be adopted for any of the proposed or existing technical
safeguards.
c. Whether the Department should extend the standard for encryption
and decryption and associated implementation specifications to require
encryption of all relevant electronic information systems.
d. Whether there should be exceptions to any of the proposed or
existing technical safeguards or related implementation specifications,
in addition to those proposed for encryption and decryption and MFA.
For example, are there any proposed or existing standards or
implementation specifications with which small or rural regulated
entities would have substantial difficulty complying? If so, please
explain the type of regulated entities that would be adversely affected
by the requirement, the nature of the compliance difficulty, and any
alternative or compensating measures that such entities are
implementing now or could implement in the event of such requirement to
address the risk to ePHI posed by the specific standard or
implementation specification.
e. Whether the exceptions the Department has proposed to the
standard for encryption or decryption are appropriate. If not, please
explain.
f. Data about the frequency and number of requests regulated
entities receive pursuant to the individual right of access at 45 CFR
164.524 where an individual requests that the regulated entity transmit
to the individual or a third party a copy of the individual's ePHI via
unencrypted email or other unencrypted messaging technologies. Please
confirm that these are requests made pursuant to the individual right
of access, rather than other types of communications, such as
appointment reminders or requests made pursuant to a valid
authorization.
g. Whether the Department should provide any additional exceptions
to standard for encryption or decryption. If so, please explain.
h. Whether there are additional criteria or parameters for
encryption that regulated entities would find helpful. If yes, please
explain and provide examples.
i. Whether the Department should require review of compensating
controls implemented to comply with an exception to the encryption and
decryption standard more frequently than once every 12 months where
there are no environmental or operational changes.
j. With respect to the exception to the standard for encryption and
decryption for certain requests made pursuant to the individual right
of access, whether there are forms and formats the Department should
include or exclude from the exception (e.g., portable document format
(PDF)). If so, please explain.
k. Resources that regulated entities have identified to help inform
individuals about the risks associated with the unencrypted
transmission of ePHI, and whether the Department should compile and
publish a list of such resources.
l. Whether the Department should define in regulation or guidance
what constitutes a prevailing cryptographic standard. If so, please
explain.
m. Whether the Department should specify the deployment of a
particular form or manner of encryption, such as the use of particular
algorithms, protocols, or compliance standards. If so, please explain.
n. Whether the Department should specify how much time regulated
entities have to implement encryption for technology assets that do not
support encryption. If so, please explain.
o. Whether the Department should provide more detailed requirements
for network segmentation, such as the type(s) of technologies that
should be segmented and how to determine whether certain technologies
should be segmented. If so, please explain.
p. Whether the exceptions the Department has proposed to the
implementation specification for MFA are appropriate. If not, please
explain.
q. Whether the Department should provide additional exceptions to
the implementation specification for MFA. If so, please explain.
r. Whether the Department should require a regulated entity to
review its compensating controls adopted to comply with the exceptions
to the implementation specification for MFA more frequently than once
every 12 months.
s. The costs and burdens for regulated entities to implement MFA.
t. Whether the Department should require regulated entities to
deploy an endpoint detection and response (EDR), security information
and event management (SIEM), or other specific solution.
u. Whether once every six months is the appropriate frequency for
the automated vulnerability scans required under the implementation
specification for vulnerability management. If not, please explain.
v. Whether the Department should define in regulation or guidance
what constitutes an authoritative source of known vulnerabilities. If
so, please explain.
w. Whether once every 12 months is the appropriate frequency for
the penetration testing required under the implementation specification
for vulnerability management. If not, please explain.
x. For regulated entities that have conducted penetration tests,
the amount of time and costs of such tests.
G. Section 164.314--Organizational Requirements
1. Section 164.314(a)(1)--Standard: Business Associate Contracts or
Other Arrangements
a. Current Provisions
The first standard in 45 CFR 164.314 contains the requirements for
business associate agreements and other arrangements. The associated
implementation specifications at 45 CFR 164.314(a)(2) require that a
business associate agreement include provisions compelling a business
associate to do all of the following: (1) comply with the requirements
of the Security Rule; \818\ (2) ensure that any subcontractors that
create, receive, maintain, or transmit ePHI on behalf of the business
associate agree to comply with the applicable requirements of the
Security Rule by also entering into a business associate agreement;
\819\ and (3) report to the covered entity any security incident of
which it becomes aware, including breaches of unsecured PHI as required
by the Breach Notification Rule.\820\
---------------------------------------------------------------------------
\818\ 45 CFR 164.314(a)(2)(i)(A).
\819\ 45 CFR 164.314(a)(2)(i)(B).
\820\ 45 CFR 164.314(a)(2)(i)(C).
---------------------------------------------------------------------------
Under 45 CFR 164.314(a)(2)(ii), a covered entity that is a
governmental entity is in compliance with the requirements of this
section if it has in place an arrangement with a business associate
that is also a governmental entity where the arrangement meets the
[[Page 981]]
analogous requirements of the Privacy Rule at 45 CFR
164.504(e)(3).\821\
---------------------------------------------------------------------------
\821\ Section 164.504(e) provides that when a covered entity and
its business associate are both governmental entities, they do not
have to negotiate a business associate agreement and may provide
adequate assurances for its uses and disclosures of PHI if they
enter into a memorandum of understanding or adopt a regulation that
has the force and effect of law that incorporates the requirements
of a business associate agreement. 65 FR 82462, 82597, 82677 (Dec.
28, 2000); see also 68 FR 8334, 8360 (Feb. 20, 2003) (Sec.
164.314(a) provisions are drawn from and intended to support the
analogous privacy protections provided for by 45 CFR 164.504(e) and
discussed in the 2000 Privacy Rule.); 78 FR 5566, 5590 (Jan. 25,
2013) (removed the specific requirements under 45 CFR 164.314 for a
memorandum of understanding when both a covered entity and business
associate are government entities and referred to the parallel
requirements of the Privacy Rule at 45 CFR 164.504(e)(3)).
---------------------------------------------------------------------------
Additionally, 45 CFR 164.314(a)(2)(iii) requires that a business
associate and its subcontractor enter into a business associate
agreement that meets the same requirements as those that apply to a
business associate agreement between a covered entity and business
associate.
As described above, a business associate agreement must include a
provision that requires a business associate to report to the covered
entity any known security incident. The term ``security incident''
includes both attempted and successful unauthorized events in an
information system.\822\ The Security Rule does not prescribe the
timing and frequency with which a business associate reports a security
incident to the covered entity (or subcontractor to a business
associate).\823\ Instead, regulated entities may determine the
appropriate timing and frequency as part of their business associate
agreement, consistent with the requirements of the Breach Notification
Rule.\824\
---------------------------------------------------------------------------
\822\ 45 CFR 164.304 (definition of ``Security incident'').
\823\ See 45 CFR 164.314(a).
\824\ Where a business associate experiences a security incident
that meets the definition of a breach at 45 CFR 164.402, the
business associate must comply with the requirements of the Breach
Notification Rule. See 45 CFR part 160 and subparts A and D of 45
CFR part 164. Specifically, the Breach Notification Rule requires a
business associate to report a breach of unsecured PHI to a covered
entity without unreasonable delay and in no case later than 60 days
from the discovery of the breach. See 45 CFR 164.410(b).
---------------------------------------------------------------------------
Depending on the size of the regulated entity, the number of
security incidents it experiences may vary, ranging from the occasional
incident experienced by a small regulated entity to more than 1,000 per
hour for a large regulated entity.\825\ Given that such incidents may
have little to no effect if the regulated entity's electronic
information systems are able to deter it, it may not be necessary for a
business associate to report the security incidents immediately to a
covered entity (or a subcontractor to a business associate).
---------------------------------------------------------------------------
\825\ Testimony of Andrew Witty, supra note 214 (According to
CEO Andrew Witty, intruders attempt to gain access to UnitedHealth
Group's electronic information systems every 70 seconds, or more
than 450,000 times per year.).
---------------------------------------------------------------------------
Additionally, as discussed above, regulated entities are required
to establish, and implement as needed, a contingency plan \826\ that
includes the policies and procedures for responding to an emergency or
other occurrence that damages systems that contain ePHI. Such
emergencies or other occurrences could include a fire, vandalism,
system failure, or a natural disaster.\827\ The Department believes
that, in some instances, a security incident would also be an emergency
or other occurrence that could require a regulated entity to activate
its contingency plan.\828\ As the Department previously explained, a
contingency plan is the only way to protect the confidentiality,
integrity, and availability of ePHI during unexpected events that may
expose ePHI because the usual security measures may be disabled,
ignored, or not observed.\829\
---------------------------------------------------------------------------
\826\ 45 CFR 164.308(a)(7)(i).
\827\ Id.
\828\ See 45 CFR 164.308(a)(7)(i); proposed 45 CFR
164.308(a)(13)(i).
\829\ 68 FR 8334, 8351 (Feb. 20, 2003).
---------------------------------------------------------------------------
b. Issues To Address
In recent years, there has been an increase in the number and types
of emergencies or other occurrences that cause damage to systems that
contain ePHI and may require a regulated entity to activate its
contingency plan. For example, we have experienced an increase in
extreme weather events over the last 40 years as a result of the
changing climate.\830\ Additionally, as discussed in greater detail
above, there has been a significant increase in the number of breaches
of unsecured PHI reported to the Department over the last five
years.\831\ And increasingly, ePHI is created, received, maintained,
and transmitted using cloud-based software that may be located in a
remote location, which means that covered entities more frequently rely
on business associates to access ePHI.\832\ Not only could the covered
entity's ability to access ePHI or the relevant electronic information
systems of the business associate that are affected by such an event,
but the incident could also have repercussions for the covered entity's
ePHI or its relevant electronic information systems. For example, a
business associate's relevant electronic information systems may become
infected with malicious software that spreads across devices connected
to a network (e.g., the NotPetya malware.\833\) If the covered entity
is also connected to the same network, providing prompt notice to the
covered entity of the security incident and activation of its
contingency plan could enable the covered entity to prevent or mitigate
damage to the covered entity's relevant electronic information systems.
---------------------------------------------------------------------------
\830\ ``Since 1980, the United States has experienced 265
weather and climate disasters in which the overall damages reached
or exceeded US$1 billion.'' Kristie L. Ebi, et al., ``Extreme
Weather and Climate Change: Population Health and Health System
Implications,'' Annual Review of Public Health (Jan. 2021), https://pubmed.ncbi.nlm.nih.gov/33406378/; see also ``Climate Change
Indicators: U.S. and Global Temperature,'' U.S. Environmental
Protection Agency (June 27, 2024) (``2023 was the warmest year on
record [. . .] and 2014-2023 was the warmest decade on record since
thermometer-based observations began.''), https://www.epa.gov/climate-indicators/climate-change-indicators-us-and-global-temperature.
\831\ ``Annual Report to Congress on HIPAA Privacy, Security,
and Breach Notification Rule Compliance, For Calendar Year 2022,''
Office for Civil Rights, U.S. Department of Health and Human
Services, p. 8 (2022) (From 2018 to 2022, the number of breaches
affecting fewer than 500 individuals increased 1 percent and
breaches affecting 500 or more individuals rose 107 percent.),
https://www.hhs.gov/sites/default/files/compliance-report-to-congress-2022.pdf.
\832\ ``Unraveling the role of cloud computing in health care
system and biomedical sciences,'' supra note 632 (``These days
numerous commercial merchants are intermingling with hospitals as
well as healthcare providers to establish healthcare-based cloud
computing networks.''); see also id. (``[. . .] Microsoft, Google
and Amazon have instantly realized that the majority of hospitals
will not continue working with servers that are privately owned as
well as controlled.''); ``Increase in health-care cyberattacks
affecting patients with cancer,'' supra note 180 (In 2021, an attack
against oncology services targeted data stored in cloud-based
systems and affected patients in several States.).
\833\ Nicole Perlroth, et al., ``Cyberattack Hits Ukraine Then
Spreads Internationally,'' The New York Times (June 27, 2017)
(discussing a worldwide ransomware attack in 2017), https://www.nytimes.com/2017/06/27/technology/ransomware-hackers.html.
---------------------------------------------------------------------------
When considered altogether, these developments mean that a
regulated entity is more likely to experience an emergency or other
occurrence that damages systems that contain ePHI than it was in either
2003 \834\ or 2013.\835\ Unfortunately, based on the Department's
experience, neither the increased risk nor the Security Rule's
requirement that a business associate notify a covered entity (or that
a subcontractor notify a business associate) of any security incident,
including breaches of unsecured PHI, has been sufficient to encourage
prompt notifications by a business associate to the covered entity (or
of a subcontractor to a business associate) that its ability to
[[Page 982]]
access ePHI or the electronic information systems that create, receive,
maintain, or transmit ePHI may be affected. This lack of prompt
notification delays a covered entity (or business associate) from
responding and protecting its ePHI and electronic information systems
accordingly.
---------------------------------------------------------------------------
\834\ See 68 FR 8334 (Feb. 20, 2003).
\835\ See 78 FR 5566 (Jan. 25, 2013).
---------------------------------------------------------------------------
c. Proposal
To address these risk trends and deficiencies in protections, the
Department proposes to add an implementation specification at proposed
45 CFR 164.314(a)(2)(i)(D) that would require a business associate
agreement to include a provision for a business associate to report to
the covered entity activation of its contingency plan that would be
required under 45 CFR 164.308(a)(13) without unreasonable delay, but no
later than 24 hours after activation.\836\ This proposal, if finalized,
would not alter the business associate's breach reporting obligations
under the Breach Notification Rule.\837\ The Department believes that
it is necessary to notify the covered entity in a timely manner of the
contingency plan activation because of the downstream implications for
such activation. Receiving such prompt notice could enable the covered
entity to take the necessary steps to protect its own relevant
electronic information systems, as well as to implement its own
contingency plan if necessary and appropriate (e.g., enable the covered
entity to access a remote or offline backup of its ePHI if necessary to
ensure that patient care is unaffected--or to reduce the effect on
patient care as much as possible). For example, in 2020, a software
company was the target of an attack that used software containing
malware to infiltrate the electronic information systems of subsequent
users of the software. This allowed cybercriminals to gain access to
several government systems and thousands of private systems
worldwide.\838\ Requiring a business associate to provide prompt notice
to the covered entity when the business associate activates its
contingency plan could enable regulated entities to maintain
individuals' confidence in their commitment to protecting the
confidentiality, integrity, and availability of ePHI in the event of an
emergency or other occurrence that adversely affects relevant
electronic information systems.\839\ Additionally, the modified
standard would align with the enhanced CPG for Third Party Incident
Reporting because this proposal would require a business associate to
both report to a covered entity or another business associate
activation of its contingency plan within 24 hours of such activation
and report known or suspected security incidents.\840\
---------------------------------------------------------------------------
\836\ A subcontractor of a business associate also would be
required to make such report to the business associate. See 45 CFR
164.314(a)(2)(iii) (applying the requirements in paragraphs
(a)(2)(i) and (ii) to business associate agreements between business
associates and subcontractors in the same manner as they apply to
business associate agreements between covered entities and business
associates).
\837\ See 45 CFR 164.410.
\838\ Saheed Oladimeji, et al., ``SolarWinds hack explained:
Everything you need to know,'' TechTarget (Nov. 3, 2023) (SolarWinds
is a software company and one of its products that was part of a
supply chain attack is an IT performance monitoring system that had
privileged access to IT systems.), https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know.
\839\ As discussed in greater detail above, the Department is
proposing to renumber the standard for the contingency plan as 45
CFR 164.308(a)(13) and to require a written contingency plan for
responding to an emergency or other occurrence that adversely
affects relevant electronic information systems, as opposed to the
current standard which applies when the emergency or other
occurrence damages information systems that contain ePHI.
\840\ Proposed 45 CFR 164.314(a)(2)(i)(C) and (D);
``Cybersecurity Performance Goals,'' supra note 18.
---------------------------------------------------------------------------
As discussed above, the Department proposes to require a regulated
entity to activate its contingency plan to respond to an emergency or
other occurrence that adversely affects relevant electronic information
systems.\841\ The Department believes that regulated entities activate
their contingency plans infrequently because such plans are only
activated when there is an emergency or other occurrence that rises to
a level beyond a security incident that is thwarted or other event that
does not adversely affect the confidentiality, integrity, or
availability of ePHI. Thus, the need to make the proposed notification
would also arise infrequently.
---------------------------------------------------------------------------
\841\ Proposed 45 CFR 164.308(a)(13)(i).
---------------------------------------------------------------------------
For example, a business associate may not be required to notify a
covered entity within a certain time after a relevant electronic
information system receives a basic internet command such as a
ping,\842\ which happens frequently. This is because a ping in and of
itself generally does not adversely affect relevant electronic
information systems when it is blocked by firewall policies, and thus
does not require activation of the regulated entity's contingency plan.
Instead, the business associate would be required to provide such
notice in instances where internet commands received by the business
associate indicate potential malicious activity, such as a denial of
service attack, leading to activation of its contingency plan because
of an event that adversely affects the business associate's relevant
electronic information systems that create, receive, maintain, or
transmit ePHI or adversely affects the confidentiality, integrity, or
availability of its ePHI. However, in both such instances, a business
associate would still be required to provide notice to the covered
entity of the ping as a security incident in accordance with the
business associate agreement.\843\
---------------------------------------------------------------------------
\842\ The ping command is a network diagnostic, and firewalls
often block incoming pings to prevent attackers from learning more
about the organization's network. Karen Scarfone, et al.,
``Guidelines on Firewalls and Firewall Policy,'' NIST Special
Publication 800-41, Revision 1, National Institute of Standards and
Technology, U.S. Department of Commerce, p. 31 (Sept. 2009), https://doi.org/10.6028/NIST.SP.800-41r1.
\843\ 45 CFR 164.314(a)(2)(i)(C).
---------------------------------------------------------------------------
The proposal itself would only require that the business associate
notify the covered entity of its activation of the contingency plan; it
does not include any specific requirements with respect to the form,
content, or manner of the notice. Instead, we propose to permit the
covered entity and business associate to negotiate such terms and
include them in their business associate agreement if they so choose.
We recognize that when such an emergency or other occurrence
transpires, the focus of the affected regulated entity must be on
activating its contingency plan and restoring access to ePHI and the
affected relevant electronic information systems. Similarly, when the
contingency plan activation is in response to a successful security
incident,\844\ it may take some time to investigate and determine the
cause of the security incident. Thus, this proposal would not require
reporting on the cause of the contingency plan activation; it would
require reporting solely on the fact that it has activated the plan.
Accordingly, we believe that 24 hours would provide a business
associate with sufficient time to do all of the following: determine
that there is an emergency or other occurrence adversely affecting the
business associate's relevant electronic information systems; determine
that it needs to activate its contingency plan; identify any covered
entities that need to be notified; and notify such covered entities.
---------------------------------------------------------------------------
\844\ While we are proposing in this NPRM in 45 CFR
164.308(a)(13)(i) to specifically include a security incident as an
example of an emergency or occurrence that may damage a relevant
electronic information system for which a contingency plan would be
required, we believe that this is a clarification, rather than a
change.
---------------------------------------------------------------------------
This proposed requirement to provide notice without unreasonable
delay, but no later than 24 hours after a
[[Page 983]]
contingency plan is activated, would also apply when a business
associate that is a governmental entity enters into an arrangement with
a covered entity that is also a governmental entity where such
arrangement meets the requirements of the Privacy Rule at 45 CFR
164.504(e)(3) in accordance with 45 CFR 164.314(a)(2)(ii) and when a
business associate enters into a business associate agreement with a
subcontractor in accordance with 45 CFR 164.314(a)(2)(iii) to notify
its business associate when it has activated its contingency plan.
Additionally, the Department proposes conforming changes to the
references of 45 CFR 164.308(b) throughout 45 CFR 164.314 consistent
with proposals made to modify 45 CFR 164.308(b). The Department does
not intend these to be substantive changes, but rather an alignment
with the proposed structural modifications in 45 CFR 164.308(b).
As discussed above, the Department proposes to remove the term
``required'' from the implementation specification at 45 CFR
164.314(a)(2) consistent with its proposal to eliminate the distinction
between addressable and required implementation specifications. We also
propose a few miscellaneous non-substantive corrections to update
citations in the standard at 45 CFR 164.314(a)(1)(i) and (a)(2)(iii).
We do not believe that these technical amendments would add or change
any regulatory, recordkeeping, or reporting requirements, nor would
they change the Department's interpretation of any regulation.
2. Section 164.314(b)(1)--Standard: Requirements for Group Health Plans
a. Current Provision
The second standard in 45 CFR 164.314 requires that, except when
ePHI disclosed to a plan sponsor is summary health information \845\ or
enrollment or disenrollment information,\846\ group health plan \847\
documents must provide that the plan sponsor will reasonably and
appropriately safeguard ePHI created, received, maintained, or
transmitted to or by the plan sponsor on behalf of the group health
plan. Section 164.314(b)(2) requires that the plan documents of a group
health plan must be amended to incorporate provisions to require the
plan sponsor to:
---------------------------------------------------------------------------
\845\ See 45 CFR 164.504(f)(1)(ii).
\846\ See 45 CFR 164.504(f)(1)(iii).
\847\ 45 CFR 160.103 (definition of ``Group health plan'').
---------------------------------------------------------------------------
Implement reasonable and appropriate administrative,
physical, and technical safeguards to protect the confidentiality,
integrity, and availability of the ePHI that it creates, receives,
maintains, or transmits on behalf of the group health plan.\848\
---------------------------------------------------------------------------
\848\ 45 CFR 164.314(b)(2)(i).
---------------------------------------------------------------------------
Ensure that the separation between the group health plan
and plan sponsor required by the Privacy Rule at 45 CFR
164.504(f)(2)(iii) \849\ is supported by reasonable and appropriate
security measures.\850\
---------------------------------------------------------------------------
\849\ 45 CFR 164.504(f)(2)(iii) requires the plan documents to
describe an employee or class of employee who receives PHI for
payment, health care operations or other matters related to the
group health plan; restrict access to PHI and use of PHI by such
employees to the plan administration functions that the plan sponsor
performs for the group health plan; and provide an effective
mechanism for resolving any issues of noncompliance by such persons.
\850\ 45 CFR 164.314(b)(2)(ii).
---------------------------------------------------------------------------
Ensure that any agent to whom it provides ePHI, agrees to
implement reasonable and appropriate security measures to protect the
information.\851\
---------------------------------------------------------------------------
\851\ 45 CFR 164.314(b)(2)(iii).
---------------------------------------------------------------------------
Report to the group health plan any security incident of
which it becomes aware.\852\
---------------------------------------------------------------------------
\852\ 45 CFR 164.314(b)(2)(iv).
---------------------------------------------------------------------------
b. Issues To Address
Plan sponsors are not directly liable for compliance with the
Security Rule because they are not regulated entities, i.e., covered
entities or business associates under HIPAA. Therefore, plan sponsors'
obligations to apply safeguards to ensure the confidentiality,
integrity, and availability of ePHI are limited to the requirements set
forth in the plan documents of its group health plan. While 45 CFR
164.314(b) generally requires that plan documents call for the
implementation of Security Rule-like safeguards, the current provision
does not specifically require the group health plan to require the plan
sponsor or any agent to whom it provides ePHI to comply with the
requirements of the Security Rule. Given the concerns we have regarding
Security Rule compliance generally by regulated entities, the
Department is also concerned that group health plans have not
sufficiently ensured that plan documents require that plan sponsors
reasonably and appropriately safeguard ePHI created, received,
maintained, or transmitted to or by the plan sponsor on behalf of the
group health plan. Additionally, the Department is concerned that group
health plans may not be monitoring plan sponsors to ensure that ePHI is
disclosed to a plan sponsor only if the plan sponsor voluntarily agrees
to use and disclose the information only as permitted or required by
the regulations.\853\
---------------------------------------------------------------------------
\853\ 65 FR 82462, 82508 (Dec. 28, 2000).
---------------------------------------------------------------------------
Plan sponsors may perform certain functions that are integrally
related to, or similar to, the administrative functions of group health
plans, and in carrying out these functions, need access to ePHI held by
the group health plan. For example, plan sponsors may perform plan
administration functions on behalf of the group health plan which are
specified in plan documents. The increase in cybercrime and other
emergencies adversely affecting electronic information systems is not
limited to regulated entities or to the health care sector; plan
sponsors are experiencing similar increases in events that require the
activation of contingency plans.\854\ And plan sponsors may not be
reasonably and appropriately protecting the confidentiality, integrity,
and availability of ePHI absent an express requirement that plan
documents obligate a plan sponsor to implement the security measures in
the Security Rule. Additionally, regulated entities may not have the
ability to determine whether alternate security measures will
accomplish the same result because they do not have access to the
information systems of plan sponsors, nor would it be appropriate for
them to have such access.
---------------------------------------------------------------------------
\854\ See ``2024 Data Breach Investigations Report,'' Verizon
Business (2024), https://www.verizon.com/business/resources/reports/dbir/.
---------------------------------------------------------------------------
Additionally, the Department believes that prompt notification by a
plan sponsor to the group health plan that the ability of the plan
sponsor or the group health plan to access ePHI or relevant electronic
information systems may be affected by a security incident is important
for the same reasons discussed above in 45 CFR 164.314(a). This lack of
prompt notification delays a group health plan from responding and
protecting its ePHI and relevant electronic information systems
accordingly.
c. Proposal
The Department proposes to modify the implementation specifications
at 45 CFR 164.314(b)(2)(i) through (iii) to address concerns that group
health plans may not recognize that reasonable and appropriate
safeguarding of ePHI requires the implementation of security measures
that are the same as, or at least equivalent to, the security measures
in the Security Rule. First, we propose to rename the implementation
specifications as ``Safeguard implementation,'' ``Separation,'' and
[[Page 984]]
``Agents,'' respectively. We also propose to modify all three
implementation specifications to require that plan documents of the
group health plan would obligate a plan sponsor or any agent to whom it
provides ePHI to implement the administrative, physical, and technical
safeguards of the Security Rule. The Department recognizes that plan
sponsors may need access to ePHI in certain situations, such as when
they perform functions that are integrally related to, or similar to,
those performed by group health plans, and we believe that such
information must be protected by plan sponsors in the same manner in
which it is protected by group health plans and other regulated
entities.\855\
---------------------------------------------------------------------------
\855\ 65 FR 82462, 82508 (Dec. 28, 2000); see also 68 FR 8334,
8360 (Feb. 20, 2003) (Sec. 164.314(b) provisions are drawn from and
intended to support the analogous privacy protections provided for
by 45 CFR 164.504(f) and discussed in the 2000 Privacy Rule.).
---------------------------------------------------------------------------
The security measures we are proposing in this NPRM are consistent
with the CISA Cross-Sector CPGs,\856\ and thus should be consistent
with measures plan sponsors are implementing to protect their own
electronic information systems, regardless of the obligations imposed
on them by plan documents. For example, the Department seeks to ensure
that plan sponsors are implementing administrative safeguards, such as
performing a risk analysis,\857\ to protect the confidentiality,
integrity, and availability of all ePHI in its information systems;
documenting required policies and procedures; and documenting
implementation of such administrative safeguards, including the
required policies and procedures.\858\ Thus, requiring plan sponsors to
implement the same security measures that regulated entities are
implementing would maintain confidence in the commitment of plan
sponsors to protecting the confidentiality, integrity, and availability
of ePHI in light of the increasing cybersecurity threats as discussed
above.
---------------------------------------------------------------------------
\856\ ``Cross-Sector Cybersecurity Performance Goals,'' supra
note 164.
\857\ Proposed 45 CFR 164.308(a)(2)(i).
\858\ Proposed 45 CFR 164.308, 164.310, 164.312, and 164.316.
---------------------------------------------------------------------------
Additionally, the Department proposes to rename the implementation
specification at 45 CFR 164.314(b)(2)(iv) as ``Security incident
awareness.''
Similar to the discussion above, the Department proposes to add a
new implementation specification for contingency plan activation at
proposed 45 CFR 164.314(b)(2)(v) that would require plan documents to
include a provision requiring a plan sponsor to report to the group
health plan without unreasonable delay, but no later than 24 hours
after activation of its contingency plan.\859\ As discussed above, the
Department believes that a group health plan needs to be notified in a
timely manner when a plan sponsor activates its contingency plan
because of the potential implications on the ability of a group health
plan to protect the confidentiality, integrity, and availability of
ePHI in its relevant electronic information systems. Accordingly, we
believe that 24 hours would provide a plan sponsor sufficient time to
do all of the following: determine that there is an emergency or other
occurrence adversely affecting the plan sponsor's relevant electronic
information systems; determine that it needs to activate its
contingency plan; activate its contingency plan; identify any group
health plans that need to be notified; and notify such group health
plans.
---------------------------------------------------------------------------
\859\ The plan sponsor would implement a contingency plan
because it is one of the requirements of the administrative
safeguards of the Security Rule and would be implemented based on
the proposed requirements in 45 CFR 164.314(b)(2)(i).
---------------------------------------------------------------------------
Similarly, as discussed above, we propose to permit the group
health plan and plan sponsor to negotiate the form, content, or manner
of the notice and include them in their plan documents if they so
choose.
The Department believes that requiring a plan sponsor to provide
prompt notice to the group health plan when the plan sponsor activates
its contingency plan would enable group health plans and plan sponsors
to maintain individuals' confidence in their commitment to protecting
the confidentiality, integrity, and availability of ePHI.
Additionally, consistent with our proposal to revise 45 CFR
164.306, the Department proposes to remove the term ``required'' from
the implementation specification at 45 CFR 164.314(b)(2) consistent
with our overall proposal to eliminate the distinction between
``required'' and ``addressable'' implementation specifications.
However, a regulated entity would still be required to comply with all
standards and implementation specifications as applicable to its
situation, as proposed in 45 CFR 164.306(c).
3. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. How group health plans currently ensure that plan sponsors
implement reasonable and appropriate administrative, physical, and
technical safeguards to protect the confidentiality, integrity, and
availability of ePHI.
b. Whether it is appropriate for group health plans to require plan
sponsors to implement the administrative, physical, and technical
safeguards of the Security Rule. If not, please explain and provide
alternatives for how the Department should ensure the confidentiality,
integrity, and availability of ePHI when it is disclosed to plan
sponsors.
c. Whether business associates currently notify covered entities
(or subcontractors notify business associates) upon activation of their
contingency plans, and if so, the manner and timing of such notice.
d. Whether plan sponsors currently notify group health plans upon
activation of their contingency plans, and if so, the manner and timing
of such notice.
e. Whether it would be appropriate to require a business associate
to notify a covered entity (or a subcontractor to notify a business
associate) within 24 hours of activating its contingency plan. If not,
please explain why and what would be an appropriate amount of time for
such notification.
f. Whether it would be appropriate to require a plan sponsor to
notify a group health plan within 24 hours of activating its
contingency plan. If not, please explain why and what would be an
appropriate amount of time for such notification.
g. The manner, timing, frequency, and process used by business
associates to report security incidents to a covered entity (or
subcontractors to business associates).
h. The manner, timing, frequency, and process used by a plan
sponsor to report security incidents to a group health plan.
H. Section 164.316--Documentation Requirements
1. Current Provisions
Section 164.316(a) requires a regulated entity to implement
reasonable and appropriate policies and procedures that comply with the
Security Rule, taking into account the size, complexity, and
capabilities of the regulated entity; \860\ the regulated entity's
technical infrastructure, hardware, and software capabilities; \861\
the costs of security measures; \862\ and the probability and
criticality of
[[Page 985]]
potential risks to ePHI.\863\ Such policies and procedures must be
consistent with the other requirements of the Security Rule. A
regulated entity is permitted to change its policies and procedures,
but it must document and implement such change in accordance with the
Security Rule.
---------------------------------------------------------------------------
\860\ 45 CFR 164.306(b)(2)(i).
\861\ 45 CFR 164.306(b)(2)(ii).
\862\ 45 CFR 164.306(b)(2)(iii).
\863\ 45 CFR 164.306(b)(2)(iv).
---------------------------------------------------------------------------
The standard and implementation specifications for documentation
are in 45 CFR 164.316(b). Paragraph (b)(1) requires a regulated entity
to maintain the policies and procedures it implements to comply with
the Security Rule in written form. Additionally, where the Security
Rule requires an action, activity, or assessment to be documented, the
regulated entity must maintain a written record of the action,
activity, or assessment. In both cases, the written record may be
electronic. Paragraph (b)(2) includes the current implementation
specifications for the documentation standard. Such documentation must
be retained for the later of either: (1) six years from its creation,
or (2) the date it was last effective. Additionally, it must be
available to those responsible for implementing the documented policies
and procedures. Finally, regulated entities must periodically review
their documentation and update it as needed in response to
environmental or operational changes affecting the security of ePHI.
2. Issues To Address
Although this section currently addresses policies and procedures
and documentation, it does not require or include standards to govern
how regulated entities must implement, maintain, and document
implementation of all security measures. Implementing, maintaining, and
documenting implementation of all security measures is important to
ensure that regulated entities make well-reasoned decisions about
implementing the requirements of this rule. Just as the Department
believes that it is necessary to consider expanding the definition of
``security measures'' to better reflect that security measures should
be multi-layered, we also believe that it is necessary to consider
providing a more complete instruction concerning how regulated entities
must implement, maintain, and document their implementation of the
required security measures.
Additionally, OCR's own experience in investigations and audits
leads us to believe that many regulated entities may not be documenting
their security measures or their implementation of those measures.\864\
It is critical for a regulated entity to commit to writing the security
measures required by the Security Rule to ensure consistent
implementation and compliance with the Security Rule. Verbal
instructions may be forgotten or misconstrued, and what the regulated
entity believes to be common knowledge may not be or may be relayed
incorrectly between workforce members.
---------------------------------------------------------------------------
\864\ See Resolution Agreement, ``Peachstate Health Management,
Inc.,'' Office for Civil Rights, U.S. Department of Health and Human
Services (Apr. 28, 2021), https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/peachstate/index.html; ``West Georgia Ambulance, Inc.,'' supra note 583; see
also ``2016-2017 HIPAA Audits Industry Report,'' supra note 121, p.
27 (the Department found that only 31 percent of regulated entities
audited had safeguarded ePHI through risk analysis activities,
including developing and implementing policies and procedures).
---------------------------------------------------------------------------
Additionally, based on OCR's enforcement experience, the Department
believes that regulated entities may not be periodically reviewing and
updating their documentation when they modify their security measures
in response to environmental or operational changes affecting the
security of their ePHI. Given the constant evolution of technology and
the everchanging behavior of cybercriminals in response to
technological evolution, the Department believes that regular review of
cybersecurity-related security measures is essential for protecting the
confidentiality, integrity, and availability of ePHI and relevant
electronic information systems.
3. Proposals
As discussed above, the Department has proposed to revise other
provisions of the Security Rule to clarify the differences between
administrative and technical safeguards and between policies and
procedures on the one hand and technical controls on the other hand. We
have also proposed to revise other provisions of the Security Rule to
clarify that a regulated entity is required to implement and maintain
its administrative, physical, and technical safeguards, including its
policies and procedures. These proposals clarify that such maintenance
requires the review, testing, and modification of the regulated
entity's security measures on a regular cadence, meaning that the
regulated entity's security measures can be modified at any time. Given
these proposals, the Department believes that we must also propose to
revise 45 CFR 164.316 to delete the standard for policies and
procedures and to modify the Security Rule's documentation
requirements. Accordingly, the Department proposes to rename this
section as ``Documentation Requirements'' and to redesignate the
documentation standard as paragraph (a). We also propose to require
that a regulated entity document how it considered the factors in 45
CFR 164.306(b) in the development of its written policies and
procedures.
We also propose to modify the documentation standard to clarify
that all required written documentation may be in electronic form.
Additionally, we propose to modify the standard's two paragraphs.
Specifically, the Department proposes at proposed 45 CFR 164.316(a)(1)
to require that a regulated entity document the policies and procedures
it has implemented to comply with the Security Rule, and as part of
that documentation, explain how it considered the factors at 45 CFR
164.306(b) in the development of its policies and procedures.
Relatedly, we also propose to modify 45 CFR 164.316(a)(2) to require a
regulated entity to document all of the actions, activities, and
assessments required by the Security Rule. The Department believes that
both proposals would help to address two common problems observed in
Security Rule investigations: a failure by the regulated entity to
document its policies and procedures and a failure to document actions,
activities, and assessments taken to comply with the Security Rule.
Without such documentation, it is challenging for a regulated entity to
assess and ensure its own compliance. Accordingly, we believe that our
proposals to require a regulated entity to document its implementation
of the Security Rule requirements would aid both the regulated entity
and the Department.
Consistent with our proposal to redesignate the documentation
standard as 45 CFR 164.316(a), we propose to redesignate the
implementation specifications for documentation time limits,
availability, and updates as proposed at 45 CFR 164.316(b)(1) through
(3), respectively. Under proposed 45 CFR 164.316(b)(3), the Department
proposes to require a regulated entity to update its documentation at
least once every 12 months and within a reasonable and appropriate
period of time after a security measure is modified.\865\ As
[[Page 986]]
discussed above, the Department recognizes that the health care
environment has changed in a way that necessitates thorough and
frequent review of and updates to documentation. By proposing to
specify how often documentation must be updated, the Department would
clarify that we expect regulated entities to review and update their
documentation at regular intervals, in addition to doing so in response
any changes to a security measure. Cybersecurity and data protection is
an evolving process, which makes formal, updated, and detailed
documentation imperative for data protection. By reviewing and updating
its documentation, including its written policies and procedures, at
least annually and in response to changes to its security measures, a
regulated entity should have a full understanding of its implemented
security measures and be able to determine which measures should be
updated to protect the confidentiality, integrity, and availability of
ePHI.
---------------------------------------------------------------------------
\865\ In 2003, the Department declined a commenter's suggestion
to change the term ``periodically'' to ``at least annually.'' At
that time, we said that documentation must be updated as needed to
reflect security measures currently in effect and that the
requirement allowed individual entities to establish review and
update cycles as deemed necessary because it would vary dependent
upon a given entity's size, configuration, environment, operational
changes, and the security measures implemented. 68 FR 8334, 8361
(Feb. 20, 2003).
---------------------------------------------------------------------------
As discussed above and consistent with the proposed changes to 45
CFR 164.306, the Department is proposing to remove the term
``required'' from 45 CFR 164.316(b)(1) through (3).
4. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following consideration in particular:
a. Whether it would be appropriate to require regulated entities to
review and update documentation for security measures at least once
every 12 months. If not, please explain.
b. Whether it is clear that 45 CFR 164.316 provides regulated
entities with directions on when and how they are to document all
security measures across all safeguard requirements. If not, please
explain.
c. Whether it is feasible for regulated entities to document all of
the actions, activities, and assessments required by the Security Rule
as proposed at 45 CFR 164.316(a)(2). If not, please explain.
I. Section 164.318--Transition Provisions
1. Current Provisions and Issues To Address
Section 164.318 established the compliance dates for the initial
implementation of the security standards for health plans, health care
clearinghouses, and health care providers in 2005 and 2006.\866\
Covered entities have been required to comply with the security
standards for almost 20 years, and the initial implementation of the
security standards is no longer applicable. Because of this, the
Department believes that these provisions are no longer necessary.
---------------------------------------------------------------------------
\866\ HIPAA set forth the compliance dates for the initial
standards. 42 U.S.C. 1320d-4; see also 68 FR 8334, 8351 (Feb. 20,
2003).
---------------------------------------------------------------------------
2. Proposal
The Department proposes to remove the information in 45 CFR 164.318
and replace the language with provisions for transitioning to the
revised Security Rule, should the proposals included in this NPRM be
adopted.
The Department understands that regulated entities may be concerned
with the anticipated administrative burden and cost of revising their
business associate agreements or other written arrangements to comply
with a revised Security Rule. For example, a regulated entity would
need to update its business associate agreements to add a provision
specifying that the business associate will report to the covered
entity \867\ that it activated its contingency plan no later than 24
hours after activation of such plan.\868\ A regulated entity may have
existing contracts that are not set to terminate or expire until after
the compliance date for a final rule modifying the Security Rule, and
we understand that a six-month compliance period may not provide enough
time to reopen and renegotiate all contracts, in addition to ensuring
that all regulated entities are compliant with the revised Security
Rule. Accordingly, the Department proposes to relieve some of the
burden on regulated entities by adding a specified period of transition
for certain existing contracts.
---------------------------------------------------------------------------
\867\ Similarly, a business associate subcontractor would need
to report to the business associate. See ``Business Associate
Contracts,'' Office for Civil Rights, U.S. Department of Health and
Human Services (June 16, 2017) (A ``business associate'' also is a
subcontractor that creates, receives, maintains, or transmits PHI on
behalf of another business associate), https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html.
\868\ Proposed 45 CFR 164.314(a)(2)(i)(D).
---------------------------------------------------------------------------
The Department's authority to provide a transition period is
expressed in 45 CFR 160.104(c), which allows the Secretary to establish
the compliance date for any modified standard or implementation
specification, considering the extent of the modification and the time
needed to comply with the modification.\869\
---------------------------------------------------------------------------
\869\ The Department has previously included transition
provisions to ensure that important functions of the health care
system were not impeded. See, e.g., 65 FR 82462 (Dec. 28, 2000); 67
FR 53182 (Aug. 14, 2002); 78 FR 5566 (Jan. 25, 2013).
---------------------------------------------------------------------------
Given these considerations, to allow regulated entities enough time
to update thousands of existing business associate agreements or other
written arrangements, the Department proposes to provide additional
time to update the contracts required by 45 CFR 164.314(a)(1).
Specifically, the Department proposes to add new transition
provisions under 45 CFR 164.318 to allow regulated entities to continue
to operate under certain existing business associate agreements or
other written arrangements until the earlier of: (1) the date such
contract or other arrangement either is renewed on or after the
compliance date of the final rule; or (2) a year after the effective
date of the final rule. The additional transition period would be
available to regulated entities if both of the following conditions are
met: (1) prior to the publication date of the final rule, the covered
entity or business associate had an existing business associate
agreement or other written arrangement with a business associate or
subcontractor, respectively, that complied with the Security Rule prior
to the effective date of a final rule revising the Security Rule; and
(2) such contract or arrangement would not be renewed or modified
between the effective date and the compliance date of the final rule.
Under the proposed transition provisions, a business associate
would be permitted to create, receive, maintain, or transmit ePHI
pursuant to an existing business associate agreement or other written
arrangement with another regulated entity that does not require the
regulated entity to obtain satisfactory assurances that meet the
requirements of the revised Security Rule for up to one year after the
revised Security Rule becomes effective, assuming that a final Security
Rule is published; and that the agreement is compliant with the
Security Rule at the time the final rule is published and that it is
not renewed or modified between the effective and compliance
dates.\870\ The transition provisions would also allow for the business
associate to create, receive, maintain, or transmit ePHI on behalf of
another regulated entity where the existing business associate
agreement does not require that the regulated entity verify that the
[[Page 987]]
business associate has deployed technical safeguards in accordance with
the Security Rule under the same circumstances as those described
above.\871\
---------------------------------------------------------------------------
\870\ See proposed 45 CFR 164.308(b)(1)(i).
\871\ See id.
---------------------------------------------------------------------------
During the transition period, the Department proposes to allow a
business associate to create, receive, maintain, or transmit ePHI
pursuant to a business associate agreement or other written arrangement
with another regulated entity without including in the agreement that
the business associate will: (1) comply with the revised Security Rule;
\872\ (2) ensure that any subcontractors that create, receive,
maintain, or transmit ePHI on behalf of the business associate agree to
comply with the revised Security Rule by entering into a business
associate agreement or other arrangement that meets the requirements of
the revised rule; \873\ and (3) report to the covered entity \874\
activation of its contingency plan.\875\
---------------------------------------------------------------------------
\872\ 45 CFR 164.314(a)(2)(i)(A).
\873\ 45 CFR 164.314(a)(2)(i)(B).
\874\ Or to the business associate from a business associate
subcontractor.
\875\ Proposed 45 CFR 164.314(a)(2)(i)(D).
---------------------------------------------------------------------------
Additionally, the Department intends that, in cases where a
contract renews automatically without any change in terms or other
action by the parties (also known as ``evergreen contracts''), such
contracts would be eligible for the extension if they automatically
renew between the effective and compliance dates. Thus, regulated
entities with an evergreen contract will be deemed to be in compliance
with the Security Rule's requirements for business associate agreements
or other written arrangements and such deemed compliance would not
terminate when these contracts automatically renew. These transition
provisions would apply to written contracts or other written
arrangements as specified above.
These transition provisions would apply only to the requirement to
amend contracts or other arrangements with business associates, and
they would not affect any other compliance obligations under the
Security Rule. For example, beginning on the compliance date of the
final rule, assuming a final rule is published and that it is finalized
as proposed, a business associate would be required to implement and
document its implementation of the administrative, physical, and
technical safeguards required by a revised Security Rule, except with
respect to 45 CFR 164.308(b) and 164.314(a), even if the business
associate's contract with the covered entity \876\ has not yet been
amended.
---------------------------------------------------------------------------
\876\ Or business associate's contract with the subcontractor.
---------------------------------------------------------------------------
Given the possibility of a similar burden on group health plans and
plan sponsors to update plan documents by the compliance date, the
Department is considering, but not proposing, a similar transition
provision for plan documents. We are not proposing such provisions at
this time because, unlike business associates, plan sponsors do not
have independent obligations under the Security Rule. Instead, the
obligations of plan sponsors are based entirely on the content of the
plan documents. Accordingly, if the plan documents are not updated,
plan sponsors are not obligated to comply with the requirements of the
Security Rule because they are not regulated entities.
In particular, the Department is considering, but not proposing at
this time, adding a new paragraph (d) introductory text under 45 CFR
164.318, with the heading ``Standard: Effect of prior plan documents
for group health plans,'' stating that notwithstanding any other
provisions of the subpart, a group health plan may allow a plan sponsor
to create, receive, maintain, or transmit electronic protected health
information pursuant to a written plan document with such group health
plan that does not comply with Sec. 164.314(b), only in accordance
with paragraph (d)(1). The Department is also considering adding a new
paragraph (d)(1) under 45 CFR 164.318, with the heading
``Implementation specification: Plan documents for group health
plans,'' stating that the requirements of paragraph (b) apply to the
plan document between a group health plan and a plan sponsor in the
same manner as such requirements apply to written contracts or other
arrangements between a covered entity and a business associate.
Similarly, the Department is considering, but not proposing at this
time, adding a new paragraph (d)(2) under 45 CFR 164.318, with the
heading ``Group health plan responsibilities,'' stating that nothing in
the section shall alter the requirements of a group health plan or plan
sponsor to comply with the applicable provisions of the part other than
Sec. 164.314(b).
3. Request for Comment
The Department requests comment on the foregoing proposals,
including any benefits, drawbacks, or unintended consequences. We also
request comment on the following considerations in particular:
a. Whether the Department's proposal to provide regulated entities
with additional time to revise business associate agreements or other
written contracts is appropriate. If not, please explain.
b. Whether the Department should also provide group health plans
and plan sponsors additional time to revise plan documents by adding a
transition provision to grandfather certain existing plan documents for
a specified period of time.
c. Whether the Department should consider additional constraints or
specificity for a new paragraph (d) to allow group health plans more
time to comply with the Security Rule requirements for plan documents.
J. Section 164.320--Severability
The Department intends that, if any provisions of this subpart,
including the provisions of this NPRM, if finalized, were held to be
invalid or unenforceable facially, or as applied to any person,
plaintiff, or stayed pending further judicial or agency action, such
provision shall be severable from other provisions of this subpart, and
from other rules and regulations currently in effect, and not affect
the remainder of this subpart. It is also our intent that, unless such
provision shall be held to be utterly invalid or unenforceable, it
shall be construed to give the provision maximum effect to the
provision permitted by law, including in the application of the
provision to other persons not similarly situated or to other
dissimilar circumstances from those where the provision may be held to
be invalid or unenforceable.
The provisions of this subpart, including the proposals of this
NPRM, are intended to operate independently of each other, even if
multiple provisions serve the same or similar general purpose(s) or
policy goal(s). Where a provision is necessarily dependent on another,
the context generally makes that clear, such as by cross-reference to a
particular standard, requirement, or implementation specification.
Where a provision that is dependent on one that is stayed or held
invalid or unenforceable, as described in the preceding paragraph, is
included in paragraph or section within 45 CFR part 160 or 164, we
intend that other provisions of such paragraph(s) or section(s) that
operate independently of said provision would remain in effect.
The Department intends the individual standards in 45 CFR 164.308,
164.310, 164.312, 164.314, and 164.316 to apply separately to govern
how a regulated entity must protect the security of all ePHI it
creates, receives,
[[Page 988]]
maintains, or transmits. Accordingly, if finalized, this provision
would provide that if any one or several standards in 45 CFR 164.308,
164.310, 164.312, 164.314, and 164.316 are deemed invalid by a court,
or non-applicable to a particular person or circumstance, all remaining
standards shall be unaffected and shall remain in force, and any
remaining component of the adjudicated provision, not invalid or found
to be unenforceable or inapplicable, shall be considered by the
Department to be still in effect.
For example, the standard for risk analysis proposed in 45 CFR
164.308(a)(2) would protect ePHI from risks and vulnerabilities to the
confidentiality, integrity, and availability of ePHI, while the
modified standard for workforce security proposed in 45 CFR
164.308(a)(9) would protect ePHI from inappropriate access by a
regulated entity's workforce. An invalidated standard for workforce
security would not render the entire rule unworkable because a
regulated entity could still meet the requirement to conduct the risk
analysis without regard to whether the entity meets the requirements
included in the standard for workforce security. Similarly, were a
court to invalidate the Department's proposal in 45 CFR 164.310(a)(1)
requiring that implemented policies and procedures to limit physical
access to relevant electronic information systems and the facility or
facilities in which they are housed be in writing, a regulated entity
could still meet a requirement to implement the policies and
procedures. Similar considerations apply to the proposal for written
policies and procedures in proposed 45 CFR 164.316(a), and to proposals
that are deemed inapplicable to certain persons or circumstances.
Further, the Department believes it is necessary to clarify how
regulated entities would continue to apply implementation
specifications in the event a court invalidates or deems inapplicable a
governing standard over a specific implementation specification, or if
a court invalidates or deems inapplicable one or several implementation
specifications without taking adverse action on the governing standard.
The Department does not interpret that this severability proposal, if
finalized, would apply to implementation specifications in the same
manner as it would apply to standards. Because the implementation
specifications are regulatory instructions on how a regulated entity is
to comply with a particular standard, if any standard is stricken, all
implementation specifications underneath are similarly stricken.
Conversely, the Department does not intend for the overarching standard
to be affected by a court's decision to invalidate or make a
determination of non-applicability to particular person or circumstance
all implementation specifications under a particular standard. The
Security Rule would still retain its flexible and scalable approach,
and, therefore, a regulated entity could use any reasonable and
appropriate security measure to implement the standard consistent with
45 CFR 164.306(b), even if all implementation specifications under the
standard are stricken.
If a court invalidates or deems inapplicable less than all
implementation specifications under a specific standard (i.e., only one
or several), the ability of a regulated entity to execute the remaining
implementation specification(s) depends on whether the remaining
implementation specifications are dependent on one another or operate
together to impose requirements on regulated entities. For example,
several proposed implementation specifications under the standard for
facility access controls at 45 CFR 164.310(a)(1) would require a
regulated entity to both establish and implement written procedures
pertaining to specific requirements such as contingency operations,
facility security planning and access control and validation, and then
subsequently review the written policies and procedures every 12
months. Should a court invalidate or deem inapplicable the
implementation specification to establish and implement written
policies procedures, the secondary specification requiring review of
said procedures would also become invalid.
The Department believes that each definition is independent of all
other definitions.
This list of examples is not intended to be exhaustive. The absence
from this list of any particular provision should not be construed to
mean that the Department considers that provision to be not severable
from other parts of the rule.
To ensure that our intent for severability of provisions is clear
in the CFR, the Department proposes to add a section on severability at
45 CFR 164.320. Proposed 45 CFR 164.320 would state our intent that if
any provision of this subpart is held to be invalid or unenforceable,
it shall be construed to give maximum effect to the provision permitted
by law unless the holding shall be one of utter invalidity or
unenforceability, in which case the provision shall be severable from
this subpart and shall not affect the remainder thereof or the
application of the provision to other persons not similarly situated or
to other dissimilar circumstances.
The Department requests comment on the foregoing proposal,
including any benefits, drawbacks, or unintended consequences.
K. New and Emerging Technologies Request for Information
Technology is constantly evolving, able to perform increasingly
complex tasks, including those with the potential to improve health
care and communication between individuals and care providers. These
new and evolved technologies will continue to transform health care in
a variety of ways, including providing regulated entities with new
tools for faster and more accurate diagnoses, effective treatments, and
more efficient administration.
As a regulated entity considers the application of new technologies
or the use of existing tools in innovative ways, it also must consider
whether these technologies create, receive, maintain, or transmit ePHI,
and, if so, how to secure them. The Security Rule was designed to be
technology-neutral for this very reason and continues to provide the
foundation for ensuring the confidentiality, integrity, and
availability of all ePHI as technology changes.\877\ As a result, while
the technology may be new or developing, securing ePHI involved with
the technology can be successfully executed through compliance with the
Security Rule.
---------------------------------------------------------------------------
\877\ 45 CFR 164.306(a).
---------------------------------------------------------------------------
Before implementing new and emerging technologies, a regulated
entity must conduct an accurate and thorough assessment of the
potential risks and vulnerabilities to the confidentiality, integrity,
and availability of ePHI.\878\ It must then implement security measures
sufficient to reduce risks and vulnerabilities to a reasonable and
appropriate level.\879\ Such administrative, physical, and technical
safeguards apply to all instances of ePHI maintained or transmitted by
the regulated entity, regardless of the technology used. Below, we
discuss some examples of new technologies, such as quantum computing,
AI, and virtual and augmented reality (VR and AR), and
[[Page 989]]
how the Security Rule would apply in each case.
---------------------------------------------------------------------------
\878\ 45 CFR 164.508(a)(1)(ii)(A).
\879\ 45 CFR 164.308(a)(1)(ii)(B).
---------------------------------------------------------------------------
1. Quantum Computing
Several Federal agencies have considered the potential benefits and
drawbacks of quantum information science,\880\ that is, the study of
``the impacts of quantum physics properties on information science.
Those properties can increase computational power and speed
significantly over classical computers, provide precision measurements;
enhance sensing capabilities; and increase the accuracy of position,
navigation, and timing services.'' \881\ According to NIST, ``In recent
years, there has been a substantial amount of research on quantum
computers--machines that exploit quantum mechanical phenomena to solve
mathematical problems that are difficult or intractable for
conventional computers.'' \882\
---------------------------------------------------------------------------
\880\ See ``Post-Quantum Cryptography, Quantum Background,''
U.S. Department of Homeland Security (last accessed July 23, 2024),
https://www.dhs.gov/quantum; see also ``Quantum-Readiness: Migration
to Post-Quantum Cryptography,'' Cybersecurity & Infrastructure
Security Agency, National Security Agency, and National Institute of
Standards and Technology, p. 1 (Aug. 21, 2023), https://media.defense.gov/2023/Aug/21/2003284212/-1/-1/0/CSI-QUANTUM-READINESS.PDF.
\881\ ``Post-Quantum Cryptography, Quantum Background,'' supra
note 880.
\882\ See ``Post-Quantum Cryptography PQC,'' Computer Security
Resource Center, National Institute of Standards and Technology,
U.S. Department of Commerce (July 19, 2024), https://www.nist.gov/pqcrypto.
---------------------------------------------------------------------------
However, the increase in computational capability threatens the
security of asymmetric cryptography,\883\ which is critical to
encryption solutions, a key protection for ePHI and other sensitive
information today. Scientists warn that when such quantum computers are
built, they will have the ability to break many of the systems for
asymmetric cryptography that are in use today.\884\ Thus, experts
anticipate that quantum computing will adversely affect the
confidentiality and integrity of digital communications.\885\ ``The
goal of post-quantum cryptography (also called quantum-resistant
cryptography) is to develop cryptographic systems that are secure
against both quantum and classical computers, and can interoperate with
existing communications protocols and networks.'' \886\ A recent
National Security Memorandum affirmed that ``alongside its potential
benefits, quantum computing also poses significant risks to the
economic and national security of the United States. . . . [including
the potential to break] much of the public-key cryptography used on
digital systems across the United States and around the world.'' \887\
Accordingly, the White House has directed Federal agencies to take
specific steps to ``mitigate the threat of [cryptanalytically relevant
quantum computers] through a timely and equitable transition of the
Nation's cryptographic systems to interoperable quantum-resistant
cryptography.'' \888\
---------------------------------------------------------------------------
\883\ See ``Post-Quantum Cryptography, Quantum Background,''
supra note 880.
\884\ See ``Post-Quantum Cryptography PQC,'' supra note 882.
\885\ Id.
\886\ See id. (removed emphasis from ``post-quantum
cryptography'' in original).
\887\ National Security Memorandum on Promoting United States
Leadership in Quantum Computing While Mitigating Risks to Vulnerable
Cryptographic Systems, National Security Memorandum/NSM-10, The
White House (May 4, 2022), https://www.whitehouse.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/.
\888\ Id.
---------------------------------------------------------------------------
NCVHS examined these security issues and provided recommendations
to the Department for applying the safeguards of the HIPAA Rules to
potential quantum computing threats. Specifically, NCVHS declared that
incorporation of recent Administration guidance for Federal agencies
``on vulnerable cryptographic systems is necessary to strengthen the
Technical Safeguards within the Security Rule.'' \889\ This joint
guidance, developed by NIST, CISA, and NSA, encourages ``the early
planning for migration to post-quantum cryptographic standards by
developing a Quantum-Readiness Road map.'' \890\ It also recommends
that organizations prepare a cryptographic inventory, discuss post-
quantum roadmaps with technology vendors, consider their supply chain's
readiness for quantum computing, and consider the responsibilities of
their technology vendors with respect to preparing for quantum
readiness.\891\
---------------------------------------------------------------------------
\889\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 2 (providing NCVHS recommendations to
strengthen the HIPAA Security Rule).
\890\ See ``Quantum-Readiness: Migration to Post-Quantum
Cryptography,'' Cybersecurity & Infrastructure Security Agency,
National Security Agency, and National Institute of Standards and
Technology, p. 1 (Aug. 21, 2023), https://media.defense.gov/2023/Aug/21/2003284212/-1/-1/0/CSI-QUANTUM-READINESS.PDF.
\891\ Id.
---------------------------------------------------------------------------
The Department encourages regulated entities to incorporate these
activities as part of their ongoing risk management programs. For
example, the steps presented in the joint guidance--surveying the
environment for potential risks and vulnerabilities that endanger ePHI,
identifying workforce members with responsibility for addressing them,
inventorying quantum-vulnerable systems, including that inventory in
its risk analysis and risk management, and working with technology
vendors to ensure their readiness--are all activities that already are
required by the administrative safeguards of the Security Rule.
We believe these obligations would be clarified by the proposals in
this NPRM. For example, the Department proposes to require that a
regulated entity not only conduct an accurate assessment of potential
risks and vulnerabilities to the confidentiality, integrity, and
availability of the ePHI it creates, receives, maintains, or transmits,
but would add an express requirement that the assessment be
comprehensive and in writing. We also propose to specify that the
required assessment include, among other things, identification of all
reasonably anticipated threats and potential vulnerabilities and
predisposing conditions, making a reasonable determination and
documentation of the likelihood that each identified threat will
exploit the identified vulnerabilities, and performing a written
assessment of the risk level for each identified threat and
vulnerability. Under the NPRM, a regulated entity would be expected to,
as part of the risk analysis, consider whether quantum computing poses
a reasonably anticipated threat to the confidentiality, integrity, or
availability of its ePHI and whether there is a vulnerability or
predisposing condition that corresponds to that threat, and to document
those considerations; make a reasonable determination and document the
likelihood that the threat will exploit the identified vulnerabilities;
and assign a risk level to the identified threat and vulnerability.
2. Artificial Intelligence (AI)
Section 238(g) of the John S. McCain National Defense Authorization
Act for Fiscal Year 2019 defined AI to include the following: \892\
---------------------------------------------------------------------------
\892\ Sec. 238(g) of Public Law 115-232, 132 Stat. 1697-98 (Aug.
13, 2018) (10 U.S.C. 2358 note) (definition of ``AI'').
---------------------------------------------------------------------------
Any artificial system that performs tasks under varying
and unpredictable circumstances without significant human oversight, or
that can learn from experience and improve performance when exposed to
data sets.
An artificial system developed in computer software,
physical hardware, or other context that solves tasks requiring human-
like perception,
[[Page 990]]
cognition, planning, learning, communication, or physical action.
An artificial system designed to think or act like a
human, including cognitive architectures and neural networks.
A set of techniques, including machine learning, that is
designed to approximate a cognitive task.
An artificial system designed to act rationally, including
an intelligent software agent or embodied robot that achieves goals
using perception, planning, reasoning, learning, communicating,
decision making, and acting.
AI requires enormous amounts of data to develop, but it also has
enormous potential benefits. The Department has previously stated that
these ``technologies have the potential to drive innovation, increase
market competition, and vastly improve care for patients and
populations.'' \893\ According to experts, ``[. . .]AI is unlocking new
possibilities by advancing medicine in entirely unimaginable ways and
solving some of the grand global healthcare challenges.'' \894\ And FDA
agrees: ``AI technologies are transforming health care by producing
diagnostic, therapeutic, and prognostic medical recommendations, or
decisions, in some cases independently, informed by the vast amount of
data generated during the delivery of health care.'' \895\ In medical
devices, areas for AI application include:
---------------------------------------------------------------------------
\893\ Kathryn Marchesini, et al., ``Getting the Best out of
Algorithms in Health Care,'' HealthITbuzz, Assistant Secretary for
Technology Policy, U.S. Department of Health and Human Services
(June 15, 2022), https://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/getting-the-best-out-of-algorithms-in-health-care.
\894\ See Nazish Khalid, et al., ``Privacy-preserving artificial
intelligence in healthcare: Techniques and applications,'' Computers
in Biology and Medicine, Volume 158, p. 1 (May 2023), https://www.sciencedirect.com/science/article/pii/S001048252300313X?ref=pdf_download&fr=RR-2&rr=8a7dac430d6d07d5.
\895\ See ``Artificial Intelligence Program: Research on AI/
[Machine Learning] ML-Based Medical Devices,'' U.S. Food & Drug
Administration, U.S. Department of Health and Human Services (June
10, 2024), https://www.fda.gov/medical-devices/medical-device-regulatory-science-research-programs-conducted-osel/artificial-intelligence-program-research-aiml-based-medical-devices.
---------------------------------------------------------------------------
Image acquisition and processing
Early disease detection
More accurate diagnosis, prognosis, and risk assessment
Identification of new patterns in human physiology and
disease progression
Development of personalized diagnostics
Therapeutic treatment response monitoring \896\
---------------------------------------------------------------------------
\896\ Id.
---------------------------------------------------------------------------
For example, clinicians are using AI to distill large volumes of
EHR information about a complex patient into a summarized note that
they can use to consider diagnoses and treatment. AI also has been used
for aid in the detection of diabetic retinopathy, screening for breast
and lung cancer, and classification of skin conditions.\897\ Others are
using ambient AI scribes, a technology that uses microphones to
transcribe encounters with patients in real-time.\898\ This tool
creates clinical documentation that clinicians can later edit, which
can lead to improved interactions with patients and reduced time on
documentation.\899\ Newer AI tools may search medical records for
relevant information regarding common conditions and other risk factors
\900\ or offer relevant questions for clinicians to pose to make an
accurate diagnosis.\901\
---------------------------------------------------------------------------
\897\ See Michael D. Howell, et al., ``Three Epochs of
Artificial Intelligence in Health Care,'' Journal of the American
Medical Association, Volume 331, Number 3 (Jan. 16, 2024), https://jamanetwork.com/journals/jama/fullarticle/2813874.
\898\ See Aaron A. Tierney, et al., ``Ambient Artificial
Intelligence Scribes to Alleviate the Burden of Clinical
Documentation,'' New England Journal of Medicine Catalyst (Feb. 21,
2024), https://catalyst.nejm.org/doi/full/10.1056/CAT.23.0404.
\899\ Id.
\900\ Julia Adler-Milstein, et al., ``Next-Generation Artificial
Intelligence for Diagnosis: From Predicting Diagnostic Labels to
`Wayfinding,''' Journal of the American Medical Association (Dec. 9,
2021), https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2787207.
\901\ Id.
---------------------------------------------------------------------------
Unfortunately, AI can also be used to harm individuals, both
intentionally and unintentionally. Bad actors are using generative AI
to threaten the privacy and security of ePHI more effectively through
phishing and other social engineering. As explained by NCVHS, ``AI
tools can create mass scale [cyberattacks] that are highly effective
and major threats to ePHI.'' \902\ Experts anticipate that AI ``will
ultimately pioneer the malicious use of [. . .] `Offensive AI'--highly
sophisticated and malicious attack code--[that] will be able to mutate
itself as it learns about its environment, and to expertly compromise
systems with minimal chance of detection.'' \903\ Such experts are
concerned about the level of destruction that will lie in its wake and
compare it to an arms race that can only escalate.\904\ Indeed, it
seems likely that regulated entities will need to invest in AI to
defend against malicious use of AI in the future.\905\
---------------------------------------------------------------------------
\902\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 8 (providing NCVHS recommendations to
strengthen the HIPAA Security Rule); see also William Dixon, et al.,
``3 ways AI will change the nature of cyber attacks,'' World
Economic Forum (June 19, 2019), https://www.weforum.org/agenda/2019/06/ai-is-powering-a-new-generation-of-cyberattack-its-also-our-best-defence/.
\903\ ``3 ways AI will change the nature of cyber attacks,''
supra note 902.
\904\ Id.
\905\ Id.
---------------------------------------------------------------------------
After assessing current and potential AI threats, NCVHS recommended
that the Department clarify how the HIPAA Rules apply to AI.\906\ We
agree with their assessment and recommendation. Specifically, ePHI,
including ePHI in AI training data, prediction models, and algorithm
data that is maintained by a regulated entity for covered functions is
protected by the HIPAA Rules and all applicable standards and
specifications.\907\ For example, generative AI tools have produced in
their output the names and personal information of persons included in
the tools' sources of training data.\908\ Similar uses of generative AI
by regulated entities, including the training of AI models on patient
data, could result in impermissible uses and disclosures, including
exposure to bad actors that can exploit the information.\909\ As part
of its risk analysis and risk management activities, a regulated entity
must consider the risk associated with different uses and data.\910\
Accordingly, we expect that a regulated entity interested in using AI
would include the use of such tools in its risk analyses and associated
risk management activities. The regulated entity's risk analysis must
include consideration of, among other things, the type and amount of
ePHI accessed by the AI tool, to whom the data is disclosed, and to
whom the output is provided. The NIST AI Risk Management Framework is a
helpful resource for regulated entities to better
[[Page 991]]
understand, measure, and manage risks, effects, and harms of AI.\911\
---------------------------------------------------------------------------
\906\ Id.
\907\ Where a regulated entity is maintaining ePHI for research
purposes as described by 45 CFR 164.512(i), the regulated entity is
not performing a covered function.
\908\ See Jordan Pearson, ``ChatGPT Can Reveal Personal
Information From Real People, Google Researchers Show,'' Vice (Nov.
29, 2023), https://www.vice.com/en/article/chatgpt-can-reveal-personal-information-from-real-people-google-researchers-show/; see
also Bridget McArthur, ``AI chatbot blamed for psychosocial
workplace training gaffe at Bunbury prison,'' ABC Southwest (Aug.
20, 2024), https://www.abc.net.au/news/2024-08-21/ai-chatbot-psychosocial-training-bunbury-regional-prison/104230980.
\909\ See Nick Easen, ``Why generative AI presents a fundamental
security risk,'' Raconteur (Sept. 9, 2024), https://www.raconteur.net/technology/why-generative-ai-presents-a-fundamental-security-threat.
\910\ See 45 CFR 164.308(a)(1)(ii)(A) and (B); proposed 45 CFR
164.308(a)(2)(i) and (a)(5)(i).
\911\ ``Artificial Intelligence Risk Management Framework, (AI
RMF 1.0),'' NIST AI 100-1, National Institute of Standards and
Technology, U.S. Department of Commerce (Jan. 2023), https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; see also ``Joint
Guidance on Deploying AI System Securely,'' Cybersecurity &
Infrastructure Security Agency, U.S. Department of Homeland Security
(Apr. 15, 2024), https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely.
---------------------------------------------------------------------------
The Security Rule requires a regulated entity to conduct repeated
risk analyses that consider any changes to its environment or
operations, such as updates or changes in technology or clinical
administration, and to apply all reasonable updated protections to
safeguard ePHI.\912\ Accordingly, as technology such as AI evolves, the
Department would expect a regulated entity to perform a risk analysis
to consider the effects of such changes on the confidentiality,
integrity, and availability of ePHI. As NCVHS observed, ``[I]t is
important to conduct risk analyses on AI throughout the life cycle of
the system.'' \913\ We believe the proposals in this NPRM would clarify
our expectations for when and how regulated entities need to consider,
prepare for, and address such changes. For example, the Department
proposes to expressly require that a regulated entity develop a written
inventory of its technology assets. Under this proposal, the Department
would expect that AI software used to create, receive, maintain, or
transmit ePHI or that interacts with ePHI, including where ePHI is used
to train the AI software, would be listed as part of its technology
asset inventory, which feeds into the regulated entity's risk analysis.
Making AI safe and secure with respect to ePHI requires efforts in a
variety of areas--biotechnology, cybersecurity, critical
infrastructure--to address risks.\914\ The Federal Government seeks to
ensure that the collection, use, and retention of ePHI is lawful and
secure, and that it mitigates privacy and confidentiality risks. Across
the administration, Federal agencies are considering potential uses for
AI, as well as their benefits and risks, consistent with E.O. 11410 and
its principles to advance and govern the development and use of
AI.\915\ These principles include making AI safe and secure and
protecting privacy and civil liberties. For example, the Department
finalized regulations earlier this year that improve transparency by
health IT developers of certified health IT, including those that are
business associates, that supply a particular type of AI--predictive
decision support interventions (DSIs).\916\ Specifically, the
regulations require such health IT developers to provide greater
transparency about the design, development, training, evaluation, and
use of such predictive DSIs.\917\ This approach promotes responsible AI
and makes it possible for covered entities to access a consistent,
baseline set of information about the algorithms they use to support
their decision making and to assess such algorithms for fairness,
appropriateness, validity, effectiveness, and safety.\918\
---------------------------------------------------------------------------
\912\ 45 CFR 164.508.
\913\ See Letter from NCVHS Chair Jacki Monson (2023), supra
note 123, Appendix p. 8.
\914\ 88 FR 75191 (Nov. 1, 2023).
\915\ Id.
\916\ 89 FR 1192 (Jan. 9, 2024).
\917\ Id.
\918\ ``Health Data, Technology, and Interoperability:
Certification Program Updates, Algorithm Transparency, and
Information Sharing,'' HTI-1 final rule, The Office of the National
Coordinator for Health IT, U.S. Department of Health and Human
Services (Mar. 7, 2024), https://www.healthit.gov/topic/laws-
regulation-and-policy/health-data-technology-and-interoperability-
certification-
program#:~:text=ONC%27s%20HTI%2D1%20final%20rule,implementation%20spe
cifications%2C%20and%20certification%20criteria.
---------------------------------------------------------------------------
Additionally, the Department proposes to require that regulated
entities monitor authoritative sources for known vulnerabilities and to
remediate such vulnerabilities in accordance with their patch
management program. We also propose to require that patches, updates,
and upgrades that address critical and high risks be applied promptly.
Together, these proposals would support the rapid response to
vulnerabilities that will be necessary as AI becomes more prevalent.
Thus, the Department believes that the adoption of the cybersecurity
best practices proposed in this NPRM is an important first step to
ensuring that AI tools are deployed by regulated entities in a manner
that protects the confidentiality, integrity, and availability of ePHI.
3. Virtual and Augmented Reality (VR and AR)
Research on VR and AR technologies is widespread and has produced
numerous applications in the health care fields. Such technologies are
being used in medical education and patient care, including AR-assisted
surgeries, VR-based pain management therapies, and immersive patient
education tools.\919\ Additionally, innovators are working on ways to
incorporate AI with VR and AR for improved diagnostics and treatment
planning.\920\
---------------------------------------------------------------------------
\919\ See Tarun Kumar Vashishth, et al., ``Virtual Reality (VR)
and Augmented Reality (AR) Transforming Medical Applications'' (Oct.
2023), https://www.researchgate.net/publication/374814301_Virtual_Reality_VR_and_Augmented_Reality_AR_Transforming_Medical_Applications.
\920\ Id.
---------------------------------------------------------------------------
However, as with quantum computing and AI, VR and AR technologies
raise new privacy and security concerns. VR and AR involve the use of
diverse technologies and the collection of a wide array of sensitive
information, including comprehensive biometric data.\921\ According to
experts, ``[. . .] VR and AR present distinct security challenges,
encompassing typical vulnerabilities associated with electronic
devices, as well as potential risks of physical harm and leakage of
highly sensitive data.'' \922\ VR, like any connected computing device,
``is susceptible to standard cybersecurity concerns and various types
of cyberthreats, necessitating proactive anticipation.'' \923\
---------------------------------------------------------------------------
\921\ See Evangelia Manika, et al., ``AR and VR devices in the
healthcare business: legal and ethical challenges,'' International
Bar Association (July 6, 2023), https://www.ibanet.org/AR-VR-devices-in-the-healthcare-business; see also Sajin Somarajan,
``Minimizing AR/VR Security And Privacy Risks,'' Infosys Digital
Experience (accessed July 23, 2024), https://blogs.infosys.com/digital-experience/mobility/minimizing-ar-vr-security-and-privacy-risks.html.
\922\ See ``AR and VR devices in the healthcare business: legal
and ethical challenges,'' supra note 921; see also ``Minimizing AR/
VR Security And Privacy Risks,'' supra note 921.
\923\ See ``AR and VR devices in the healthcare business: legal
and ethical challenges,'' supra note 921; see also ``Minimizing AR/
VR Security And Privacy Risks,'' supra note 921.
---------------------------------------------------------------------------
These cybersecurity risks, such as hacking, social engineering,
malicious software, and ransomware, can be mitigated through holistic
risk analysis and risk management, consistent with the Security Rule
administrative standards in 45 CFR 164.308. In addition, patch
management,\924\ access control,\925\ authentication,\926\ and
appropriate business associate agreements \927\ are examples of some of
the required safeguards that would apply to VR and AR systems.
---------------------------------------------------------------------------
\924\ See proposed 45 CFR 164.308(a)(4)(i).
\925\ 45 CFR 164.312(a)(1).
\926\ 45 CFR 164.312(d); see proposed 45 CFR
164.308(a)(10)(ii)(C) and 164.312(f)(1).
\927\ 45 CFR 164.308(b) and 164.314(a).
---------------------------------------------------------------------------
We believe the proposals in this NPRM to clarify these safeguards
would substantially improve the ability of regulated entities to
address these cybersecurity risks. For example, the Department proposes
to require that a regulated entity obtains from a business associate
written verification that the business associate has deployed the
technical safeguards required by the Security Rule, including a written
analysis of the business associate's information systems from a person
with
[[Page 992]]
appropriate knowledge of and experience with generally accepted
cybersecurity principles and methods for ensuring the confidentiality,
integrity, and availability of ePHI verifying compliance with the
requirements of 45 CFR 164.312 and a written certification that the
analysis has been performed and is accurate. Under this proposal, a
regulated entity would be required to obtain such verification from a
business associate-developer of VR/AR software, ensuring that ePHI that
is created, received, maintained, or transmitted using the VR/AR
software is protected to the same extent as ePHI that is created,
received, maintained, or transmitted using other technology assets that
are components of the regulated entity's relevant electronic
information systems.
Many regulated entities are piloting innovative technologies. Such
entities generally have separate departments that research, develop,
test, and deploy such technologies.\928\ Regulated entities might
consider integrating workforce members with expertise in security and
privacy into their technology development groups to ensure that privacy
and security, including the Security Rule-required safeguards, are
embedded into the design of new and emerging technologies.\929\ Doing
so can help improve security ``while boosting quality, efficiency, and
productivity.'' \930\
---------------------------------------------------------------------------
\928\ See Raj Mehta, et al., ``The future of cyber in the future
of health. The evolving role of cybersecurity in health care,''
Deloitte (2020), https://www2.deloitte.com/us/en/pages/advisory/articles/future-of-cybersecurity-healthcare.html.
\929\ Id.
\930\ Id. regarding ``DevSecOps.''
---------------------------------------------------------------------------
4. Request for Comment
The Department requests comment on the foregoing discussion of how
the Security Rule protects ePHI used in new and developing
technologies, including any benefits, drawbacks, or unintended
consequences. We also request comment on the following considerations
in particular:
a. Whether the Department's understanding of how the Security Rule
applies to new technologies involving ePHI is not comprehensive and if
so, what issues should also be considered.
b. Whether there are technologies that currently or in the future
may harm the security and privacy of ePHI in ways that the Security
Rule could not mitigate without modification, and if so, what
modifications would be required.
c. Whether there are additional policy or technical tools that the
Department may use to address the security of ePHI in new technologies.
V. Regulatory Impact Analysis
A. Executive Order 12866 and Related Executive Orders on Regulatory
Review
The Department of Health and Human Services (HHS or ``Department'')
has examined the effects of this proposed rule under Executive Order
(E.O.) 12866, Regulatory Planning and Review,\931\ E.O. 13563,
Improving Regulation and Regulatory Review,\932\ E.O. 14094,
Modernizing Regulatory Review,\933\ the Regulatory Flexibility Act
\934\ (RFA), the Unfunded Mandates Reform Act of 1995 \935\ (UMRA), and
E.O. 13132 on Federalism.\936\ E.O.s 12866 and 13563 direct the
Department to assess all costs and benefits of available regulatory
alternatives and, when regulation is necessary, to select regulatory
approaches that maximize net benefits (including potential economic,
environmental, public health and safety, and other advantages;
distributive effects; and equity). The proposed rule meets the criteria
as significant under section 3(f)(1) of E.O. 12866, as amended by E.O.
14094.
---------------------------------------------------------------------------
\931\ 58 FR 51735 (Oct. 4, 1993).
\932\ 76 FR 3821 (Jan. 21, 2011).
\933\ 88 FR 21879 (Apr. 11, 2023).
\934\ Public Law 96-354, 94 Stat. 1164 (Sept. 19, 1980)
(codified at 5 U.S.C. 601-612).
\935\ Public Law 104-4, 109 Stat. 48 (Mar. 22, 1995) (codified
at 2 U.S.C. 1501).
\936\ 64 FR 43255 (Aug. 4, 1999).
---------------------------------------------------------------------------
The RFA requires us to analyze regulatory options that would
minimize any significant effect of a rule on small entities. As
discussed in greater detail below, this analysis concludes, and the
Secretary certifies, that the notice of proposed rulemaking (NPRM), if
adopted, would not result in a significant economic effect on a
substantial number of small entities.
The UMRA (section 202(a)) generally requires us to prepare a
written statement, which includes an assessment of anticipated costs
and benefits, before proposing ``any rule that includes any Federal
mandate that may result in the expenditure by State, local, and Tribal
governments, in the aggregate, or by the private sector, of
$100,000,000 or more (adjusted annually for inflation) in any 1 year.''
\937\ The current threshold after adjustment for inflation is $183
million, using the most current (2024) Implicit Price Deflator for the
Gross Domestic Product. UMRA does not address the total cost of a rule.
Rather, it addresses certain categories of cost, mainly Federal mandate
costs resulting from imposing enforceable duties on State, local, or
Tribal governments or the private sector; or increasing the stringency
of conditions in, or decreasing the funding of, State, local, or Tribal
governments under entitlement programs.
---------------------------------------------------------------------------
\937\ Sec. 202 of Public Law 104-4, 109 Stat. 64 (Mar. 22, 1995)
(codified at 2 U.S.C. 1532(a)).
---------------------------------------------------------------------------
This proposed rule, if adopted, would impose mandates that would
result in the expenditure by State, local, and Tribal governments, in
the aggregate, or by the private sector, of more than $183 million in
any one year. The impact analysis in this proposed rule addresses such
effects both qualitatively and quantitatively. Each covered entity and
business associate (collectively, ``regulated entity''), including
government entities that meet the definition of covered entity (e.g.,
State Medicaid agencies), would be required to: conduct a Security Rule
compliance audit; report to covered entities or business associates, as
applicable, upon activation of their contingency plan; deploy multi-
factor authentication (MFA) in and penetration testing of relevant
electronic information systems; complete network segmentation; disable
unused ports and remove extraneous software; update cybersecurity
policies and procedures; revise business associate agreements; and
update workforce training. Business associates would be required to
conduct an analysis and provide verification of their compliance with
technical safeguards and covered entities would be required to obtain
verification from business associates (and business associates from
their subcontractors). Additionally, group health plans would need to
revise plan documents to require plan sponsors to comply with
administrative, physical, and technical safeguards according to the
Security Rule standards. Finally, through contractual language, health
plan sponsors would need to enhance safeguards for electronic protected
health information (ePHI) according to the Security Rule standards.
Costs for all regulated entities to change their policies and
procedures alone would increase costs above the UMRA threshold in one
year, and costs of health plan sponsors would increase total costs
further. Although Medicaid makes Federal matching funds available for
States for certain administrative costs, these are limited to costs
specific to operating the Medicaid program. There are no Federal funds
directed at Health Insurance Portability and Accountability Act of 1996
(HIPAA) compliance activities.
The Department believes that pursuant to Subtitle E of the Small
Business Regulatory Enforcement
[[Page 993]]
Fairness Act of 1996,\938\ the Office of Management and Budget's
(OMB's) Office of Information and Regulatory Affairs would be likely to
determine that when finalized, this rule meets the criteria set forth
in 5 U.S.C. 804(2) because it is projected to have an annualized effect
on the economy of more than $100,000,000.
---------------------------------------------------------------------------
\938\ Also referred to as the Congressional Review Act, 5 U.S.C.
801 et seq.
---------------------------------------------------------------------------
The Justification for this Rulemaking and Summary of Proposed Rule
Provisions section at the beginning of this preamble contain a summary
of this rule and describe the reasons it is needed. We present a
detailed analysis below.
1. Summary of Costs and Benefits
The Department identified ten categories of quantifiable costs
arising from these proposals that would apply to all regulated
entities: (1) conducting a Security Rule compliance audit; (2)
obtaining written verification from their business associates or
subcontractors that the business associates or subcontractors,
respectively, have conducted the required verification of compliance
with technical safeguards; (3) notifying other regulated entities when
workforce members' access to ePHI is terminated; (4) completing network
segmentation; (5) disabling ports and removing extraneous software; (6)
deploying MFA; (7) deploying penetration testing; (8) updating policies
and procedures; (9) updating workforce training programs; and (10)
revising business associate agreements. Additionally, group health
plans would be required to update plan documents to require health plan
sponsors' compliance with the administrative, physical, and technical
safeguards according to the Security Rule and notification of group
health plans when health plan sponsors activate their contingency plan.
Business associates would have additional obligations to verify
compliance with technical safeguards and provide it in writing to
covered entities (and subcontractors to business associates) and to
notify covered entities upon activation of their contingency plans.
Finally, although plan sponsors are not directly subject to the HIPAA
Rules, by virtue of the plan document requirements, the Department
estimates that certain group health plan sponsors (e.g., employers that
provide group health benefits) would likely incur some quantifiable
costs to improve safeguards for their electronic information systems
that affect the confidentiality, integrity, or availability of ePHI and
to notify group health plans upon activation of plan sponsors'
contingency plan.
The Department estimates that the first-year costs attributable to
this proposed rule total approximately $9 billion. These costs are
associated with regulated entities and health plan sponsors engaging in
the regulatory actions described above. For years two through five,
estimated annual costs of approximately $6 billion are attributable to
costs of recurring compliance activities. Table 1 reports the present
value and annualized estimates of the costs of this proposed rule
covering a 5-year time horizon. Using a 2 percent discount rate, the
Department estimates that this proposed rule would result in annualized
costs of $6.8 billion for regulated entities and health plan sponsors
combined.
Table 1--Accounting Table, Costs of the Proposed Rule, $ Billions \a\
----------------------------------------------------------------------------------------------------------------
Primary Period
Costs estimate Year dollars Discount rate covered
----------------------------------------------------------------------------------------------------------------
Present Value......................... $34 2023 Undiscounted............ 2026-2030
Present Value......................... 32 2023 2%...................... 2026-2030
Annualized............................ 7 2023 2%...................... 2026-2030
----------------------------------------------------------------------------------------------------------------
\a\ Figures are rounded.
As a result of the proposed changes in this NPRM, the enhanced
security posture of regulated entities would likely reduce the number
of breaches of ePHI and mitigate the effects of breaches that
nonetheless occur. The Department has partially quantified these
effects and presents them in a break-even analysis. The break-even
analysis estimates that if the proposed changes in the NPRM reduce the
number of individuals affected by breaches by 7 to 16 percent, the
revised Security Rule would pay for itself. Alternatively, the same
cost savings may be achieved by lowering the cost per affected
individual's ePHI by 7 percent ($35) to 16 percent ($82), respectively.
The changes to the Security Rule would likely result in important
benefits and some costs that the Department is unable to fully quantify
at this time. As explained further below, unquantified benefits include
reductions in reputational, financial, and legal harm from breaches of
individuals' ePHI, reductions in disruptions to health care delivery,
increased confidence among parties to health care business
transactions, and improved quality of health care.
Table 2--Potential Non-Quantified Benefits
------------------------------------------------------------------------
Benefits \a\
-------------------------------------------------------------------------
Would benefit individuals by shielding them from unwanted disclosure of
their ePHI and resulting reputational, financial, and legal harms from
ePHI misuse.
Would reduce reputational damage to regulated entities resulting from
breaches.
Would increase confidence among parties to health care business
transactions that ePHI is protected to a higher degree than previously.
Would reduce risk of breaches of ePHI by health plan sponsors.
Would help to prevent health care cost increases to recoup financial
losses from responding to breaches.
Would help guard against potential data loss.
Would help minimize potential disruption of service for individuals
served by any of the affected entities.
------------------------------------------------------------------------
\a\ Some of the items in this list represent differing perspectives on
the same effect. In such cases, if more thorough quantification became
feasible, we would take steps to avoid double-counting when summing
the quantitative estimates.
[[Page 994]]
The Department also recognizes that there may be some costs that
are not readily quantifiable, notably, actions that regulated entities
may take to comply with existing requirements more fully as a result of
proposed clarifications. For example, this would include completing a
technology asset inventory, which is a baseline expectation for the
existing requirement of conducting a risk assessment; documenting
completion of existing requirements; adding more specificity to the
required contingency plan, such as designating staff roles with
specific responsibilities when a contingency occurs; testing safeguards
as part of reviewing and updating policies and procedures and technical
controls; and deploying encryption for ePHI in a more concerted manner
(including documenting provision of notification in response to
individuals' access requests for transmission of ePHI in an unencrypted
manner and has been informed of the risks associated with the
transmission, receipt, and storage of unencrypted ePHI). These
activities are specified in the NPRM, but they would be more in the
nature of clarifications to and increased specificity of existing
requirements. Because the degree of additional effort by regulated
entities to meet these requirements would be dependent on multiple
factors and likely to be highly variable, the additional cost is
difficult to quantify.
We acknowledge that there may be a small burden associated with
documenting that an individual was informed of the risks of unencrypted
transmission of ePHI; however, we believe there are few requests that
fall into this category. Because we do not have a basis to make an
estimate, we have requested data on potential burdens associated with
this proposed exception to the proposed standard for encryption in the
preamble discussion of 45 CFR 164.312.
The cost of complying with the exceptions to encryption and MFA for
medical devices authorized by the U.S. Food & Drug Administration for
marketing may depend in part on the extent to which a regulated entity
relies on legacy devices because the regulated entity may be required
to adopt compensating controls. New devices are likely to have
encryption and MFA built into them, not requiring compensating
controls. The Department is unable to estimate the range of costs to
adopt compensating controls for legacy devices because there is no
reliable data to accurately assess the extent to which legacy devices
are used in the United States.\939\ The Department requests comment on
the number of legacy devices in use and the costs of applying
compensating controls to such devices.
---------------------------------------------------------------------------
\939\ ``Next Steps Toward Managing Legacy Medical Device
Cybersecurity Risks,'' supra note 742, p. 6.
---------------------------------------------------------------------------
2. Baseline Conditions
The Security Rule, in conjunction with the Privacy and Breach
Notification Rules, protects the privacy and security of individuals'
PHI, that is, individually identifiable health information (IIHI). The
Security Rule's protections are limited to ePHI, while the Privacy and
Breach Notification Rules protect both electronic and non-electronic
PHI. The Security Rule establishes standards to protect individuals'
ePHI and requires reasonable and appropriate administrative, physical,
and technical safeguards. The Security Rule specifies a series of
administrative, physical, and technical security requirements that must
be performed or implemented for regulated entities to safeguard ePHI.
Specifically, entities regulated by the Security Rule must: (1) ensure
the confidentiality, integrity, and availability of all ePHI they
create, receive, maintain, or transmit; (2) protect against reasonably
anticipated threats to the security and integrity of the information;
(3) protect against reasonably anticipated impermissible uses or
disclosures; and (4) ensure compliance by their workforce. A major goal
of the Security Rule is protecting the security of individuals' health
information while allowing for the development of a health information
system to improve the efficiency and effectiveness of the health care
system.
The Administrative Simplification provisions of HIPAA (title II)
provide the Secretary of HHS with the authority to publish standards
for the privacy and security of health information. The Department
first proposed standards for the security of ePHI on August 12, 1998,
and published a final rule on February 20, 2003. The Department
modified the Security Rule in 2013. Recently, as the preamble to this
NPRM discusses, changes in the health care environment and insufficient
compliance by regulated entities with the existing Security Rule
require the modifications proposed here.
For purposes of this Regulatory Impact Analysis (RIA), the proposed
rule adopts the list of covered entities (with an updated count) and
certain cost assumptions identified in the Department's Information
Collection Request (ICR) associated with the HIPAA Privacy Rule to
Support Reproductive Health Care Privacy (``2024 ICR'').\940\ The
Department also relies on certain estimates and assumptions from the
1998 Proposed Rule \941\ that remain relevant, the 2003 Final
Rule,\942\ and the 2013 Omnibus Rule,\943\ as referenced in the
analysis that follows.
---------------------------------------------------------------------------
\940\ ``View ICR,'' Office of Information and Regulatory
Affairs, Office of Management and Budget (July 9, 2024), https://www.reginfo.gov/public/do/PRAViewICR?ref_nbr=202401-0945-002.
\941\ 63 FR 43242 (Aug. 12, 1998).
\942\ 68 FR 8334 (Feb. 20, 2003).
\943\ 78 FR 5566 (Jan. 25, 2013).
---------------------------------------------------------------------------
The Department quantitatively analyzes and monetizes the effect
that this proposed rule would have on the actions of regulated entities
to: conduct a Security Rule compliance audit; provide or obtain
verification of business associates' compliance with technical
safeguards; notify other regulated entities when workforce members'
access to ePHI is altered or terminated; notify covered entities or
business associates, as applicable, upon activation of a contingency
plan; complete network segmentation; disable unused ports and remove
extraneous software; deploy MFA and penetration testing; update health
plan documents; update policies and procedures; update workforce
training; and revise business associate agreements. The Department also
quantitatively analyzes the effects on group health plan sponsors for
ensuring that safeguards for their relevant electronic information
systems meet Security Rule standards and notifying group health plans
upon activation of the plan sponsors' contingency plans.
Additionally, the Department quantitatively analyzes the benefits
of the proposed modifications to regulated entities due to an expected
reduction in costs of remediation of breaches and risk of breaches by
regulated entities.
The Department analyzes the remaining benefits and costs
qualitatively because many of the proposed modifications are
clarifications of existing requirements and predicting other concrete
actions that such a diverse scope of regulated entities might take in
response to this rule is inherently uncertain.
Analytic Assumptions
The Department bases its assumptions for calculating estimated
costs and benefits on several publicly available datasets, including
data from the U.S. Census Bureau (``Census''), the U.S. Department of
Labor's (DOL) Bureau of Labor Statistics, the Small Business
Administration (SBA), and the Department's Centers for Medicare &
[[Page 995]]
Medicaid Services (CMS) and Agency for Healthcare Research and Quality
(AHRQ). For the purposes of this analysis, the Department assumes that
employee benefits plus indirect costs equal approximately 100 percent
of pre-tax wages and adjusts the hourly wage rates by multiplying by
two, for a fully loaded hourly wage rate. The Department adopts this as
the estimate of the hourly value of time for changes in time use for
on-the-job activities.
Implementing the proposals likely would require regulated entities
to engage workforce members or consultants for certain activities. The
Department assumes that an information security analyst would perform
most of the activities proposed in the NPRM, consistent with the
existing Security Rule requirements. The Department expects that a
computer and information systems manager would revise policies and
procedures, a training and development specialist would revise the
necessary workforce training, a lawyer would revise business associate
agreements, and a compensation and benefits manager would revise health
plan documents for plan sponsors. To the extent that these assumptions
affect the Department's estimate of costs, the Department solicits
comment on its assumptions, particularly assumptions in which the
Department identifies the level of workforce member (e.g., analyst,
manager, licensed professional) that would be engaged in activities and
the amount of time that particular types of workforce members spend
conducting activities related to this RIA as further described below.
Table 3 lists pay rates for occupations referenced in the cost
estimates for the NPRM.
Table 3--Occupational Pay Rates \944\
------------------------------------------------------------------------
Fully loaded 2023 Average
Occupation code and title hourly wage hourly wage
------------------------------------------------------------------------
15-1212 Information Security Analysts... $119.94 $59.97
13-1151 Training and Development 69.20 34.60
Specialists............................
11-3111 Compensation and Benefits 145.14 72.57
Manager................................
11-3021 Computer and Information Systems 173.76 86.88
Managers...............................
23-1011 Lawyers......................... 169.68 84.84
13-1111 Management Analysts............. 111.08 55.54
43-0000 Office and Administrative 46.10 23.05
Support Occupations....................
------------------------------------------------------------------------
The Department assumes that most regulated entities would be able
to incorporate changes to their workforce training into existing
cybersecurity awareness training programs and Security Rule training
rather than conduct a separate training because the total time frame
for compliance from date of publication of a final rule would be 240
days.\945\
---------------------------------------------------------------------------
\944\ See ``Occupational employment and wages--May 2023,'' U.S.
Department of Labor, Bureau of Labor Statistics, Table 1. National
employment and wage data from the Occupational Employment and Wage
Statistics survey by occupation (Apr. 3, 2024), https://www.bls.gov/news.release/pdf/ocwage.pdf.
\945\ This includes 60 days from publication of a final rule to
the effective date and an additional 180 days until the compliance
date.
---------------------------------------------------------------------------
Regulated Entities Affected
The changes proposed in this NPRM would apply to covered entities
(i.e., health care providers that conduct covered electronic
transactions, health plans, and health care clearinghouses) and their
business associates (including subcontractors). The Department
estimates the number of covered entities to be 822,600 business
establishments (see table 4). By calculating costs for establishments,
rather than firms,\946\ some burdens may be overestimated because
certain costs would be borne by a parent organization rather than each
separate facility. Similarly, benefits and transfers would be
overestimated because entity assumptions flow through to those
quantifications. However, decisions about the level of an organization
that is responsible for implementing certain requirements likely varies
across the health care industry. The Department requests data on the
extent to which certain burdens are borne by each facility versus an
umbrella organization.
---------------------------------------------------------------------------
\946\ A firm may be an umbrella organization that encompasses
multiple establishments.
---------------------------------------------------------------------------
According to Census data,\947\ there are 954 Direct Health and
Medical Insurance Carrier firms out of a total 5,822 Insurance Carrier
firms, such that health and medical insurance firms make up
approximately 16.4 percent of insurance firms [= 954/5,822].\948\ Also,
according to Census data, there are 2,506 Third Party Administration of
Insurance and Pension Funds firms and 8,375 establishments. This
category also includes clearinghouses. The Department assumes that 16.4
percent of these firms service health and medical insurance because
that is equivalent to the share of insurance firms that are health and
medical. As a result, the Department estimates that 411 firms
categorized as Third Party Administrators are affected by the proposals
in this NPRM [= 2,506 x .164]. Similarly, the Department estimates that
1,374 associated establishments would be affected by the proposals in
this NPRM [= 8,375 total establishments x .164]. Most of these are
business associates. Based on data from the Department's HIPAA audits
and experience administering the HIPAA Rules, we are aware of
approximately 36 clearinghouses. See table 4 below.
---------------------------------------------------------------------------
\947\ ``2021 [Statistics of U.S. Businesses] SUSB Annual Data
Tables by Establishment Industry,'' United States Census Bureau,
U.S. & States, 6-digit NAICS (Dec. 2023), https://www.census.gov/data/tables/2021/econ/susb/2021-susb-annual.html.
\948\ This percentage was rounded.
---------------------------------------------------------------------------
There were 56,289 community pharmacies, including 19,261 pharmacy
and drug store firms, operating in the U.S. in 2023.\949\ Small
pharmacies generally use pharmacy services administration organizations
(PSAOs) to provide administrative services, such as conducting
negotiations. Based on information from industry, the Department
estimates that the proposed rule would affect fewer than 10 PSAOs and
we include this within the estimated 1 million business associates
affected by the proposals in this NPRM.\950\ The Department assumes
that
[[Page 996]]
costs affecting pharmacies are incurred at each pharmacy and drug store
establishment and each PSAO.
---------------------------------------------------------------------------
\949\ See ``2023 NCPA Digest, sponsored by Cardinal Health,''
National Community Pharmacists Association, Table 5, p. 9 (2023),
https://www.cardinalhealth.com/content/dam/corp/web/documents/Report/cardinal-health-2023-ncpa-digest.pdf; see also ``2021
[Statistics of U.S. Businesses] SUSB Annual Data Tables by
Establishment Industry,'' supra note 947.
\950\ See Scott Pace, ``The Role and Value of Pharmacy Services
Administrative Organizations (PSAOs),'' Impact Management Group, p.
3 (July 20, 2022), https://content.naic.org/sites/default/files/call_materials/The%20Role%20and%20Value%20of%20Pharmacy%20Services%20Administrative%20July%202022.pdf; see also ``The Role of Pharmacy Services
Administrative Organizations for Independent Retail and Small Chain
Pharmacies,'' Avalere Health, p. 4 (Sept. 30, 2021), https://documents.ncsl.org/wwwncsl/Foundation/sponsor-views/The_Role_of_PSAOs_Independent_Pharmacies.pdf.
Table 4--Estimated Number, Type, and Size Threshold of Covered Entities
----------------------------------------------------------------------------------------------------------------
Covered Entities
-----------------------------------------------------------------------------------------------------------------
Small business
administration
NAICS code Type of entity Firms Establishments (SBA) size
threshold \c\
(million)
----------------------------------------------------------------------------------------------------------------
524114............................. Health and Medical 954 5,552 $47
Insurance Carriers.
524292............................. Clearinghouses \a\.... 36 36 47
622................................ Hospitals............. 3,095 7,465 47
446110............................. Pharmacies \b\........ 31,671 56,289 37.5
6211-6213.......................... Office of Drs. & Other 429,476 527,951 9-16
Professionals.
6215............................... Medical Diagnostic 8,714 19,477 19-41.5
Laboratories &
Imaging.
6214............................... Outpatient Care....... 26,084 54,642 19-47
6219............................... Other Ambulatory Care. 10,547 16,114 20.5-40
623................................ Skilled Nursing & 42,421 95,175 16-34
Residential
Facilities.
6216............................... Home Health Agencies.. 27,433 38,040 19
532283............................. Home Health Equipment 488 1,859 41
Rental.
----------------------------------------------------
Total.......................... ...................... 580,9198 822,600 .................
----------------------------------------------------------------------------------------------------------------
\a\ This North American Industry Classification System (NAICS) category includes clearinghouses and is titled
``Third Party Administration of Insurance and Pension Funds.'' The number of clearinghouses is based on the
Department's research.
\b\ Number of pharmacies is taken from industry statistics.
\c\ See ``Table of Small Business Size Standards,'' U.S. Small Business Administration (Mar. 17, 2023), https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standards_Effective%20March%2017%2C%202023%20%282%29.pdf. The SBA size thresholds are
discussed in Section V.C. Regulatory Flexibility Act--Small Entity Analysis of this NPRM.
The Department also estimated the percentage of rural and urban
health care providers by matching health care provider data from
CMS,\951\ Health Resources & Services Administration,\952\ and the
Statistics of U.S. Businesses (SUSB) \953\ with county population data
from the U.S. Census Bureau.\954\ We determined whether a health care
provider was rural or urban based on OMB's standards for delineating
metropolitan and micropolitan statistical areas.\955\ Consistent with
OMB's standard, we considered a county to be rural if it has fewer than
50,000 inhabitants.\956\ This includes micropolitan areas (towns and
cities between 10,000 and 49,999) and counties outside of metropolitan
statistical areas and micropolitan areas. Based on this analysis, we
estimate that 7-8 percent of health care providers operate in rural
areas.
---------------------------------------------------------------------------
\951\ See ``Provider of Services File--Internet Quality
Improvement and Evaluation System--Home Health Agency, Ambulatory
Surgical Center, and Hospice Providers,'' Centers for Medicare &
Medicaid Services (2024), https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-internet-quality-improvement-and-evaluation-system-home-health-agency-ambulatory-surgical-center-and-hospice-providers; ``Provider
of Services File--Hospital & Non-Hospital Facilities,'' Centers for
Medicare & Medicaid Services (2024), https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-hospital-non-hospital-facilities.
\952\ See ``Area Health Resources Files,'' Health Resources &
Services Administration, U.S. Department of Health and Human
Services (2022-2023 County Level Data), https://data.hrsa.gov/data/download?data=AHRF#AHRF.
\953\ See ``2021 [Statistics of U.S. Businesses] SUSB Annual
Data Tables by Establishment Industry,'' supra note 947.
\954\ See ``Delineation Files,'' U.S. Census Bureau, U.S.
Department of Commerce (2023), https://www.census.gov/geographies/reference-files/time-series/demo/metro-micro/delineation-files.html.
\955\ See generally 86 FR 37770 (July 16, 2021).
\956\ See 86 FR 37770, 37778 (July 16, 2021).
---------------------------------------------------------------------------
Estimated Number and Type of Business Associates
The Department adopts the estimate of approximately 1,000,000
business associates (including subcontractors) as stated in the 2024
ICR and the 2013 ``Modifications to the HIPAA Privacy, Security,
Enforcement, and Breach Notification Rules Under the Health Information
Technology for Economic and Clinical Health [HITECH] Act and the
Genetic Information Nondiscrimination Act, and Other Modifications to
the HIPAA Rules'' final rule.\957\ We considered whether to increase
this figure in our updates but did not do so because many business
associates serve multiple covered entities. We lack sufficient data to
estimate the number of such businesses more precisely, but we believe
that the number of business associates is highly dynamic and dependent
on multiple market factors, including expansion and consolidation among
various lines of business, changing laws and legal interpretations, and
emerging technologies. We include subcontractors of business associates
within our estimate because they are business associates of business
associates.
---------------------------------------------------------------------------
\957\ 78 FR 5565 (Jan. 25, 2013).
---------------------------------------------------------------------------
The Department welcomes comments on the number or type(s) of
regulated entities that would be affected by the proposals in this
proposed rule and the extent to which they may experience costs or
other burdens not already accounted for in the cost estimates. The
Department also requests comment on the number of health plan documents
that would need to be revised, if any. The Department additionally
requests detailed comment on any situations, other than those
identified here, in which covered entities or business associates would
be affected by the proposals in this rulemaking.
Health Plan Sponsors
Within this NPRM, the Department is for the first time including
estimates of health plan sponsors' potential costs of compliance with
specific
[[Page 997]]
administrative, physical, and technical safeguards of the Security
Rule. The Department relied on data from AHRQ and the U.S. Census to
estimate the number of firms offering group health plans (1.9
million),\958\ and multiplied that by the percentage that offer at
least one self-insured plan to calculate the number of plan sponsors
that would be likely to receive ePHI and be subject to the requirements
of 45 CFR 164.314(b) [1,943,484 x .382 = 742,411]. We solicit comments
on whether group health plans or third-party administrators address any
Security Rule requirements for plan sponsors, so the plan sponsors
would not have an additional burden or would have a smaller burden than
estimated below.
---------------------------------------------------------------------------
\958\ See ``Medical Expenditure Panel Survey--Insurance
Component,'' Tables I.A.1 and I.A.2, Agency for Healthcare Research
and Quality (2023), https://meps.ahrq.gov/data_stats/summ_tables/insr/national/series_1/2023/ic23_ia_g.pdf?_gl=1*16xft35*_ga*MTE0MDI5NzI0LjE3MDk2NjQ0NDM.*_ga_45NDTD15CJ*MTczMTEwMzQ4OS4yLjEuMTczMTEwMzUzNS4xNC4wLjA (showing the
number of establishments and percent offering health plans) and
``County Business Patterns: 2021,'' United States Census Bureau
(April 27, 2023), https://www.census.gov/data/datasets/2021/econ/cbp/2021-cbp.html (providing the ratio of firms to establishments).
We assume one health plan sponsor per firm that offers a self-
insured group health plan.
---------------------------------------------------------------------------
Individuals Affected
The number of individuals potentially affected by the proposed
changes to the Security Rule includes most of the United States
population (approximately 337 million), specifically those who have
received any health care in the past seven years and whose ePHI is
likely created, received, maintained, or transmitted by a regulated
entity. Statistics about the number of individuals affected by breaches
of PHI provide insight into known instances where safeguards were
breached, although the effects of the Security Rule extend farther than
that, to all ePHI. Data from the 2022 Annual Report to Congress on
Breaches of Unsecured Protected Health Information for Calendar Year
2022 \959\ revealed nearly 42 million individuals affected by breaches
of PHI in that year. Third-party sources reported approximately 133
million individuals affected by health care breaches in 2023.\960\
According to UnitedHealth Group, the 2024 breach of its clearinghouse
subsidiary Change Healthcare may have affected approximately one-third
of the U.S. population, or 112 million individuals.\961\ The Department
believes that the range of individuals potentially affected by the
proposed regulatory changes would be from 42 million to 337 million.
---------------------------------------------------------------------------
\959\ See ``Annual Report to Congress on Breaches of Unsecured
Protected Health Information for Calendar Year 2022,'' supra note
213, p. 9 (2023).
\960\ See Steve Alder, ``December 2023 Healthcare Data Breach
Report,'' The HIPAA Journal (Jan. 18, 2024), https://www.hipaajournal.com/december-2023-healthcare-data-breach-report/.
\961\ See ``What We Learned: Change Healthcare Cyber Attack,''
U.S. House of Representatives Committee on Energy & Commerce (May 3,
2024), https://energycommerce.house.gov/posts/what-we-learned-change-healthcare-cyber-attack.
---------------------------------------------------------------------------
HIPAA Breach Data
The Department has reported HIPAA/HITECH breach data annually since
2009. Table 5 shows the data as reported to Congress for the past five
years. We relied on this data, combined with breach cost data from
industry sources, to analyze the potential savings of the NPRM.
Table 5--Breaches of PHI
--------------------------------------------------------------------------------------------------------------------------------------------------------
Small breaches (fewer than 500 Large breaches (500+ affected Total
affected individuals) individuals) -------------------------------
Year ----------------------------------------------------------------
Affected Affected Breach count Affected
Breach count individuals Breach count individuals individuals
--------------------------------------------------------------------------------------------------------------------------------------------------------
2018.................................................... 63,098 296,948 302 12,196,601 63,400 12,493,549
2019.................................................... 62,771 284,812 408 38,732,966 63,179 39,017,778
2020.................................................... 66,509 312,723 656 37,641,403 67,165 37,954,126
2021.................................................... 63,571 319,215 609 37,182,558 64,180 37,501,773
2022.................................................... 63,966 257,105 626 41,747,613 64,592 42,004,718
--------------------------------------------------------------------------------------------------------------------------------------------------------
3. Costs of the Proposed Rule
Below, the Department provides the basis for its estimated
quantifiable costs resulting from the proposed changes to specific
provisions of the Security Rule. Many of the estimates are based on
assumptions formed through OCR's experience with compliance and
enforcement and accounts from stakeholders. For each cost, the
Department provides its main estimate, as well as additional high and
low estimates for some costs to account for any uncertainty in the
compliance approach of regulated entities.
All estimates in this section are based on subject matter
expertise. The Department requests information or data points from
commenters to further refine its estimates and assumptions.
a. Costs Associated With Conducting a Security Rule Compliance Audit
The Department estimates that all regulated entities would need to
conduct a Security Rule Compliance Audit because this would be a new
requirement under proposed 45 CFR 164.308(a)(14). Although some
regulated entities have mistakenly conducted such an audit in lieu of a
risk analysis, the Department believes that costs for the compliance
audit as a separate requirement should be attributed to the proposed
changes in the NPRM. Further, because this would be an annual
requirement, the Department is including this as a recurring cost. The
Department estimates that regulated entities would need an average of 2
hours of labor by an information systems analyst to conduct the
compliance audit, based on the assumption that regulated entities have
already documented Security Rule compliance activities as currently
required. This would result in total estimated costs of $437,205,288 [=
1,822,600 regulated entities x 2 hours x $119.94]. The respective low
and high estimates would be 0.25 and 2.5 hours of information systems
analyst labor, resulting in respective total estimated costs of
$54,650,6611 [= 1,822,600 regulated entities x 0.25 hours x $119.94]
and $546,506,610 [= 1,822,600 regulated entities x 2.5 hours x
$119.94].
[[Page 998]]
b. Estimated Costs From Adding a Requirement for Business Associates to
Analyze Compliance With Technical Safeguards
For proposed 45 CFR 164.308(b), the Department estimates that
business associates that handle ePHI would need to spend an average of
2 hours (with a low estimate of 0.25 hours and high estimate of 2.5
hours) analyzing how their cybersecurity measures comply with the
proposed requirements for technical safeguards and producing a
verification report for covered entities at the hourly wage rate of an
information security analyst. This estimate assumes that business
associates have already documented existing safeguards, policies, and
procedures, so that the costs attributable to the new requirement are
incremental and would total approximately $239,880,000 [1 million
business associates x 2 hours x $119.94], with a low estimate of
$29,985,000 [1 million business associates x 0.25 hours x $119.94] and
high estimate of $299,850,000 [1 million business associates x 2.5
hours x $119.94].
c. Costs Arising From Covered Entities and Business Associates
Obtaining Verification From Business Associates of Compliance With
Technical Safeguards
Under 45 CFR 164.308(b), the Department further estimates that each
covered entity would need to spend an average of 30 minutes (with 15
minutes as a low estimate and 90 minutes as a high estimate) requesting
and obtaining compliance reports from its business associates about
their deployment of technical safeguards required by the Security Rule
at the hourly wage of an information security analyst. This assumes
that in most instances, business associates would produce the required
verification for covered entities without being prompted by a request
because they would be required to do so by the Security Rule, as
proposed in the NPRM. It further assumes that covered entities have
readily available means of contacting business associates, such as via
email, and that the contact could be a single email draft sent in a
batch. The average time burden per entity depends on verification
frequency, likely influenced by entities' average number of business
associates and how frequently entities change business associates. The
low estimate assumes that entities verify less frequently, whereas the
high estimate assumes entities verify more frequently. At the wage rate
of an information security analyst, this would result in estimated
total costs for covered entities of $49,331,322 [= 822,600 covered
entities x 0.5 hours x $119.94], with a low estimate of $24,665,661 [=
822,600 covered entities x 0.25 hours x $119.94] and high estimate of
$147,993,966 [= 822,600 covered entities x 1.5 hours x $119.94].
The proposed requirement to obtain verification of compliance with
technical safeguards also would apply to business associates with
respect to their subcontractors. However, we believe that a much
smaller number of business associates rely on subcontractors compared
to the number of covered entities that rely on business associates to
conduct activities on their behalf. Thus, we estimate that, on average,
business associates would need 5 minutes annually to obtain
verification from their subcontractors that the subcontractors have
complied with technical safeguards as required by the Security Rule.
The estimate includes only the time needed for business associates to
send a mass email to subcontractors because we have already addressed
the burden on business associates of producing the verification in the
previous section and that estimate includes burdens on subcontractors.
The high estimate for this activity would be an average of 15 minutes
per business associate, and a low estimate would be for business
associates to 2 minutes on this activity. At the wage rate of an
information security analyst, this would add estimated total costs for
business associates of $9,995,000 [= 1,000,000 business associates x
0.083 hours x $119.94], with a high estimate of $29,985,000 [=
1,000,000 business associates x .25 hours x $119.94].
d. Cost Related to Notification of Termination or Change of Workforce
Members' Access to ePHI
The Department estimates that regulated entities are likely to
incur additional costs to implement a process to notify other regulated
entities when a workforce member's access to ePHI is terminated or
changed under proposed 45 CFR 164.308(a)(9)(ii). This estimate assumes
that notifications will take an average of 1 hour annually per
regulated entity. This results in new estimated costs totaling
$84,021,860 [= 1,822,600 regulated entities x 1 hour x $46.10].\962\
---------------------------------------------------------------------------
\962\ See table 3, wage rate for Office and Administrative
Support Occupations.
---------------------------------------------------------------------------
e. Cost Related to Regulated Entities Deploying Multi-Factor
Authentication
The Department estimates that, on average, regulated entities would
have an information security analyst spend 1.5 hours deploying MFA, as
specifically required under proposed 45 CFR 164.312(f)(2)(ii). This
would be a one-time, first-year burden that includes an average of 30
minutes for a regulated entity to select an MFA solution that allows
them to meet the requirements of the proposal without creating workflow
disruptions or delays. This estimate would vary depending on how
prevalent MFA is in the industry when and if the requirements of the
NPRM are finalized. As a widely accepted information security practice,
the Department believes that many large entities have already deployed
MFA and the costs range from zero to only a few dollars per user. The
low estimate would be 01 hours on average (assuming that many entities
already have some form of MFA), and the high estimate would be 1.75
hours (assuming that few entities have MFA). At the loaded wage rate of
an information security analyst, the total estimated cost would be
$327,903,966 [= 1,822,600 regulated entities x 1.5 hours x $119.94],
with a low estimated total of $218,602,644 [= 1,822,600 regulated
entities x 1 hour x $119.94] and a high estimated total of $382,554,627
[= 1,822,600 regulated entities x 1.75 hours x $119.94]. The Department
applies this cost in the first year only because minimal additional
labor is needed to maintain this safeguard once it has been deployed.
f. Costs Related to Network Segmentation
The Department believes that most large regulated entities and many
medium-sized regulated entities have segmented their information
networks to some degree; however, additional actions may be needed to
more fully protect ePHI as required under proposed 45 CFR
164.312(a)(2)(vi). Further, small entities may not have been aware of
the importance of segmenting networks or taken steps to segment their
networks. The Department estimates that each regulated entity would
spend an average of 4.5 hours to set up network segmentation in the
first year of compliance with a final rule (with a low estimate of 4
hours and a high estimate of 5 hours) at the hourly wage of an
information security analyst. The Department further assumes that in
the following years, the burden to maintain the segmented network would
be minimal and incorporated into the maintenance requirements. The
total first year estimated cost of the network segmentation requirement
would be $983,711,898 [= 1,822,600 regulated entities x 4.5 hours x
$119.94] with a low estimated total of $874,410,576 [= 1,822,600
regulated entities x 4 hours x
[[Page 999]]
$119.94] and a high estimate of $1,093,013,220 [= 1,822,600 regulated
entities x 5 hours x $119.94].
g. Cost Related to Disabling Ports and Removing Extraneous Software
The Department believes that large regulated entities have already
disabled unused network ports and removed extraneous software as part
of existing configuration requirements. However, the Department
believes that small and medium-sized regulated entities are less likely
to have performed these actions and thus would incur a new burden to
implement these aspects of configuration management proposed at 45 CFR
164.312(c)(2)(ii) and (iv). The Department estimates that 629,796
establishments are owned by small and medium-sized covered
entities,\963\ which is approximately 76.56 percent of all covered
entities [= 629,796/822,600]. The Department applies that percentage to
the estimated number of business associates [= 0.7656 x 1,000,000] to
arrive at the estimated number of regulated entities with quantifiably
increased burdens from these proposed requirements to disable unused
ports and remove extraneous software. We estimate that for these
1,395,396 regulated entities [= 629,796 covered entities + 765,600
business associates], an average annual burden of 30 minutes would be
needed at the wage rate of an information security analyst to make
needed changes to configuration management, specifically disabling
unused ports and removing extraneous software. This would result in
estimated total cost increases of $83,681,898 [= 1,395,3960 regulated
entities x 0.5 hours x $119.94], with a low estimate of $41,840,949 [=
1,395,396 regulated entities x 0.25 hours x $119.94] based on an
estimated annual burden of 15 minutes per affected entity and a high
estimate of $109,301,322 [= 1,822,600 regulated entities x 0.50 hours x
$119.94] based on an estimated annual burden of 30 minutes for all
regulated entities.
---------------------------------------------------------------------------
\963\ As defined by having 500 or fewer employees. See ``2021
[Statistics of U.S. Businesses] SUSB Annual Data Tables by
Establishment Industry,'' supra, note 947.
---------------------------------------------------------------------------
h. Costs Related to Regulated Entities Conducting Penetration Testing
The Department estimates that each regulated entity would spend an
average of 3 hours conducting penetration testing (with a low estimate
of 2 hours and a high estimate of 10 hours) at the hourly wage of an
information security analyst. The Department expects that there might
be a high degree of variability between entities depending on their
size and technological sophistication. Large entities have more
endpoints to test, and thus have greater exposure. The Department also
believes there is room for significant variability in the effort that
regulated entities may apply to this activity. At the wage rate of an
information security analyst, this would result in estimated total
annual costs for regulated entities of $655,807,932 [= 1,822,600
regulated entities x 3 hours x $119.94], with a low estimated total of
$437,205,288 [= 1,822,600 regulated entities x 2 hours x $119.94] and
high estimated total of $2,186,026,440 [= 1,822,600 regulated entities
x 10 hours x $119.94].
i. Costs Arising From Reporting Contingency Plan Activation
The Department estimates that business associates would need to
notify other regulated entities in the event that they activate their
contingency plan once business associate agreements are revised
according to proposed 45 CFR 164.314(a)(2)(i)(D). The Department
believes this is unlikely to occur more frequently than once per year
and that the time to do so would be minimal because the proposed
requirement does not specify the means or scope of such notification.
The Department estimates that business associates would need an average
of 30 minutes (with 15 minutes as a low estimate and 45 minutes as a
high estimate) to report to other regulated entities, as applicable,
when their contingency plan is activated at the wage rate of an
information security analyst for a total annual cost of $59,970,000 [=
1,000,000 business associates x 0.5 hours x $119.94], with a low
estimated total of $29,985,000[= 1,000,000 business associates x 0.25
hours x $119.94] and high estimated total of $89,955,000 [= 1,000,000
business associates x 0.75 hours x $119.94].
j. Revised Health Plan Documents
The Department estimates that health care insurers and third-party
administrators would need to revise health plan documents to reflect
that health plan sponsors that receive ePHI (that is not limited to
summary health information or disenrollment information) are protecting
ePHI with the administrative, physical, and technical safeguards
detailed in the Security Rule, as proposed. These 6,162 entities
collectively would be responsible for updating approximately 742,411
health plan documents at the wage rate of a compensation and benefits
manager. The Department's estimate assumes that on average each plan
document requires 30 minutes to update for a total estimated cost of
$53,876,766 [1742,411 x 0.5 hours x $145.14]. The Department has
attributed these costs solely to health plans and not health plan
sponsors because the health plan is the regulated entity.
k. Estimated Costs for Developing New or Modified Policies and
Procedures
The Department anticipates that regulated entities would need to
develop new or modified policies and procedures for the proposed new
requirements to obtain or provide verification of business associates'
compliance with the Security Rule's requirements for technical
safeguards, conducting a Security Rule compliance audit, and reporting
the activation of a contingency plan, as well as other proposed
changes, depending on the regulated entities' existing policies and
procedures. The Department estimates that the costs associated with
developing such policies and procedures would be the labor of a
computer and information systems manager for an average of 3.5 hours
(with 2.5 hours as a low estimate and 6 hours as a high estimate,
depending on the number of entities with written policies and
procedures, and their degree of specificity). This would result in
total annual costs of $1,108,432,416 [= 1,822,600 regulated entities x
3.5 hours x $173.76], with a low estimated total of $791,737,440 [=
1,822,600 regulated entities x 2.5 hours x $173.76] and high estimated
total of $1,900,169,856 [= 1,822,600 regulated entities x 6 hours x
$173.76]. The existing rule requires updates to policies and procedures
in response to environmental or operational changes affecting the
security of the ePHI, and as a result, the Department is estimating
additional costs for new policies related to this proposed rule as an
incremental increase.
l. Costs Associated With Training Workforce Members
The Department anticipates that regulated entities would be able to
incorporate new content into existing Security Rule training programs
and that the costs associated with doing so would be attributed to the
labor of a training specialist for an estimated 2 hours for total
annual costs of $252,247,840 [= 1,822,600 regulated entities x 2 hours
x $69.20]. The low estimate for this activity is $126,123,920 [=
1,822,600 regulated entities x 1 hour x $69.20], and the high estimate
is $378,371,760 [= 1,822,600 regulated entities x 3 hours x $69.20].
Many of the changes in the NPRM require the
[[Page 1000]]
adoption of standard cybersecurity practices as applied specifically to
address the confidentiality, integrity, and availability of ePHI, so we
expect that an information security analyst would be familiar with this
content. These estimated costs would address any required revisions to
training for workforce members within the first year of compliance with
a final rule. Any further recurring component is likely to be
implemented into regularly scheduled employee training and thus would
not be directly attributable to the proposals in this NPRM.
m. Revising Business Associate Agreements
The NPRM proposes to provide a transition period in proposed 45 CFR
164.318 for regulated entities to revise business associate agreements
to comply with the proposed changes to the requirements of the Security
Rule. The proposed transition period would allow regulated entities to
revise existing agreements by the earlier of the contract renewal date
that falls after the compliance date of a final rule, or within one
year of the rule's effective date. For a large share of existing
agreements, this would allow regulated entities to complete the
revisions on a rolling basis according to the dates they are renewed.
The Department estimates that 1,822,600 \964\ business associate
agreements would need to be revised if this NPRM is adopted and that,
on average, the portion of this activity that results from the rule's
modifications would take an hour of a lawyer's time for each regulated
entity. This would result in annual costs of $309,258,768 [= 1,822,600
regulated entities x 1 hour x $169.68]. The Department recognizes that
this estimate may not fully account for all revised business associate
agreements. However, the Department believes that in some instances,
one hour of time is more than would be needed. We also believe it is
likely that, for some regulated entities, a professional other than a
lawyer would be responsible for the revised agreements at a lower
hourly wage. For some large business associates, the Department
believes that a single agreement is used for most of its customers. The
Department's estimates assume that most agreements would be revised
within the first year and accounts for all of them within that time
period. This would be considered a one-time cost; in other words, it is
not carried over into future years. As with all the estimates in this
NPRM, the Department invites comments about the assumptions underlying
the proposed cost projections.
---------------------------------------------------------------------------
\964\ This is the estimated total number of covered entities and
business associates.
---------------------------------------------------------------------------
n. Plan Sponsors' Obligations
Proposed 45 CFR 164.314(b)(2) would mandate that group health plan
documents require their health plan sponsors who receive ePHI that is
not limited to summary health information or enrollment or
disenrollment information to deploy the administrative, physical, and
technical safeguards for ePHI required by the Security Rule and notify
their group health plans upon activation of the plan sponsors'
contingency plan. Currently, plan documents must require such health
plan sponsors to have safeguards in place, but not necessarily the
safeguards specified in the Security Rule.\965\ The Department
estimates that an additional 52.42 hours of labor would be needed for
each affected health plan sponsor to bring its security safeguards for
ePHI into compliance with the Security Rule standards and to notify
group health plans when its contingency plan is activated, over and
above the actions attributable to safeguards already in place for ePHI
and for sponsors' electronic information systems generally. The
Security Rule compliance activities attributed to group health plan
sponsors are shown in table 7, below.
---------------------------------------------------------------------------
\965\ See 45 CFR 164.314(b) (requiring that a group health plan
ensure that its plan documents provide that the plan sponsor will
reasonably and appropriately safeguard electronic protected health
information created, received, maintained, or transmitted to or by
the plan sponsor on behalf of the group health plan).
---------------------------------------------------------------------------
Most compliance activities would be performed by a workforce member
at the hourly wage rate of an information security analyst ($119.94),
while documentation of maintenance would be performed at the rate of a
management analyst ($111.08) and notification of termination or change
of workforce members' access to ePHI would be performed by an office
administrative assistant ($46.10). This would result in estimated total
first year costs for health plan sponsors of $4,658,781,219 as shown in
detail in table 7.
o. Total Quantifiable Costs
The Department summarizes in tables 6 and 7 the estimated costs
that regulated entities (approximately $4,655 million) and plan
sponsors (approximately $4,659 million), respectively, would experience
in the first year of implementing the proposed regulatory changes. The
Department anticipates that these costs would be for the following
activities: conducting a Security Rule compliance audit; obtaining
verification of business associates' and subcontractors' compliance
with technical safeguards; providing verification of business
associates' compliance with technical safeguards; providing
notification of termination or change of workforce members' access to
ePHI; deploying MFA and penetration testing; segmenting networks;
disabling unused ports; removing extraneous software; notifying covered
entities or business associates, as applicable, upon activation of a
contingency plan; and updating health plan documents, policies and
procedures, workforce training, and business associate agreements.
These costs would also include health plan sponsors deploying
safeguards for their relevant electronic information systems to meet
Security Rule standards and notifying group health plans upon
activation of a plan sponsor's contingency plan.
Table 6--First Year Cost Estimates for Regulated Entities' Proposed Compliance Obligations \a\
----------------------------------------------------------------------------------------------------------------
Total annual
Compliance activities Burden hours x Respondents Wage rate cost
frequency (millions)
----------------------------------------------------------------------------------------------------------------
Security Rule Compliance Audit........ 2 x 1 1,822,600 Regulated $119.94 $437
Entities.
BA Verification of Technical 2 x 1 1,000,000 Business 119.94 240
Safeguards. Associates.
Obtain BA Compliance Verification..... .5 x 1 822,600 Covered Entities 119.94 49
Obtain Subcontractors' Compliance .083 x 1 1,000,000 Business 119.94 10
Verification. Associates.
Notification of Workforce Members' 1 x 1 1,822,600 Regulated 46.10 84
Termination of access to ePHI. Entities.
[[Page 1001]]
Multi-factor Authentication........... 1.5 x 1 1,822,600 Regulated $119.94 $328
Entities.
Network Segmentation.................. 4.5 x 1 1,822,600 Regulated 119.94 984
Entities.
Configuration Management.............. .5 x 1 1,395,396 Regulated 119.94 84
Entities.
Penetration Testing................... 3 x 1 1,822,600 Regulated 119.94 656
Entities.
Notification of Contingency Plan .5 x 1 1,000,000 Business 119.94 60
Activation. Associates.
Update Health Plan Documents.......... .5 x 120 3,102,851 Health Plan 145.14 54
Documents.
Update Policies and Procedures........ 3.5 x 1 1,822,600 Regulated 173.76 1,108
Entities.
Update Workforce Training............. 2 x 1 1,822,600 Regulated 69.20 252
Entities.
Revise Business Associate Agreements.. 1 x 1 1,822,600 Regulated 169.68 309
Entities.
-------------------------------------------------------------------------
Total Annual Cost Burden.......... .............. ........................ .............. 4,655
----------------------------------------------------------------------------------------------------------------
\a\ These represent first year estimated costs and are rounded.
The Department presents the estimated cost of health plan sponsors'
compliance with the proposed new requirements in table 7 below.
Table 7--First Year Cost Estimates of Health Plan Sponsors' Proposed Compliance Obligations \a\
----------------------------------------------------------------------------------------------------------------
Total annual
Compliance activities Burden hours x Respondents Wage rate cost
frequency (millions)
----------------------------------------------------------------------------------------------------------------
Risk Analysis--Documentation.......... 5 x 1 742,411 Plan Sponsors... $119.94 $445
Information System Activity Review-- .75 x 12 742,411 Plan Sponsors... 119.94 801
Documentation.
Ongoing Education..................... .17 x 12 742,411 Plan Sponsors... 119.94 178
Security Incidents (other than 2 x 12 742,411 Plan Sponsors... 119.94 2,137
breaches)--Documentation.
Contingency Plan--Testing and Revision 2 x 1 742,411 Plan Sponsors... 119.94 178
Contingency Plan--Criticality Analysis .5 x 1 742,411 Plan Sponsors... 119.94 45
Notification of Workforce Members' .25 x 1 742,411 Plan Sponsors... 46.10 9
Termination of ePHI Access.
Maintenance Records................... .5 x 12 742,411 Plan Sponsors... 111.08 495
Multi-factor Authentication........... 1.5 x 1 742,411 Plan Sponsors... 119.94 133
Configuration Management.............. .5 x 1 742,411 Plan Sponsors... 119.94 45
Penetration Testing................... 2 x 1 742,411 Plan Sponsors... 119.94 178
Notification of Contingency Plan .17 x 1 742,411 Plan Sponsors... 119.94 15
Activation.
-------------------------------------------------------------------------
Total Annual Cost Burden.......... .............. ........................ .............. 4,659
----------------------------------------------------------------------------------------------------------------
\a\ These represent first year estimated costs and are rounded.
Together, regulated entities' and affected health plan sponsors'
estimated first year costs of compliance with the proposals in the NPRM
would be approximately 9,314 million (or $9 billion).
p. Costs Borne by the Department
The covered entities that are operated by the Department would be
affected by the changes in a similar manner to other covered entities,
and such costs have been factored into the estimates above. The
Department has not identified other costs to the Department related to
the changes in the NPRM. A reduction in the number of large breaches
(affecting 500 or more individuals per incident) would benefit the
Department by enabling it to focus its resources on a smaller number of
breach investigations, and potentially resolve such investigations more
quickly.
4. Benefits of the Proposed Rule
a. Quantitative Analysis of Benefits
A key goal of strengthening the cybersecurity posture of regulated
entities is to reduce the number and severity of security incidents,
including breaches of ePHI. The Department believes that compliance
with the proposed changes, which align with industry guidelines and
best practices, would benefit regulated entities by reducing the cost
of breaches. Although the costs of implementing the proposed
cybersecurity measures would be significant, the costs of responding to
breaches of ePHI are much higher. According to industry data, the
average cost of a health care breach in 2023 rose to $10.93 million,
the highest among all industries studied,\966\ and the per record cost
of a breach involving personally identifiable information (across all
industries) was $183.\967\ These costs include detection and
investigation activities, notification activities, post-breach response
activities, and activities attempting to minimize the loss of business.
Thus, the benefits of the proposed rule would be to reduce the harms of
health care breaches described in the preamble. The Department believes
that implementing the changes in the NPRM would reduce both the
incidence of breaches in health care and the costs of mitigating
breaches when they occur.
---------------------------------------------------------------------------
\966\ See ``Cost of a Data Breach Report 2023,'' supra note 131,
p. 13.
\967\ Id. at 18.
---------------------------------------------------------------------------
The Department also analyzed the potential cost savings of
proposals that
[[Page 1002]]
correspond to major factors affecting the costs of large breaches as
identified in published reports.\968\ The Department estimates that, at
a minimum, performing the following actions would quantifiably reduce
costs: (1) encryption; (2) penetration testing; (3) requiring MFA and
notification of termination of access to ePHI; (4) increasing employee
training; and (5) reducing noncompliance with regulations. These
factors would account for an estimated 23.6 percent decrease in large
breach costs.\969\ For health care breaches, this corresponds to an
estimated cost savings of $2.6 million per large breach in high
incidence years, and $2.1 million per large breach in low incidence
years.
---------------------------------------------------------------------------
\968\ The impact factor costs and cost savings are based on
estimates for all breaches from the annual IBM Security and Ponemon
Institute Costs of a Data Breach Reports for years 2018-2023. See
id. at p. 28.
\969\ The Department calculated the percentage decrease as a
share of the sum of factor costs from the average breach cost:
($218,915 + $180,358 + $187,703 + $221,593 + $232,867)/$4,450,000 =
0.236.
---------------------------------------------------------------------------
Non-Quantitative Analysis of Benefits
A fundamental benefit of the proposed rule would be to decrease the
effects of breaches on individuals who are the subjects of ePHI, namely
patients and health plan members. Breaches of ePHI may cause harm to
individuals in many ways, including loss of reputation and personal
dignity and financial and medical fraud, which may result in false
debts, impaired credit, and even health threats from misuse of health
insurance credentials by another individual. ``[H]ealthcare data, which
includes medical histories and personal identification, can last a
lifetime. The information collected can be used for ransom, to commit
tax frauds, to provide supporting disability documentation, to send
fake bills to insurance providers, to obtain healthcare, prescription
drugs, medical treatment, and to obtain government benefits like
Medicare and Medicaid.'' \970\ Hackers can use stolen personal,
medical, and financial data to take out a bank loan in the victim's
name and change direct deposit information in payroll systems, allowing
them to steal wages as well.\971\ In addition, medical identity fraud
can impact the victim's credit score and health insurance premiums, and
may result in unexpected legal fees.\972\ Medical identity fraud also
enables thieves to obtain medical treatment using the victim's stolen
ePHI. This can lead to the thief's medical conditions being
incorporated into the victim's medical records and impacting the
victim's ability to receive appropriate medical treatment based on
accurate records in the future, or any care at all depending on whether
the thief has exhausted the victim's insurance benefits.\973\ Overall,
recovering compromised ePHI and addressing the consequences of breached
information can be a long and arduous process that can cost victims
large amounts of time, energy, and money.\974\
---------------------------------------------------------------------------
\970\ See ``New Dangers in the New World: Cyber Attacks in the
Healthcare Industry,'' supra note 135, p. 3.
\971\ See ``Is the HIPAA Security Rule Enough to Protect
Electronic Personal Health Information (PHI) in the Cyber Age? ''
supra note 207; see also Adam Wright, et al., ``The Big Phish:
Cyberattacks Against U.S. Healthcare Systems,'' Journal of General
Internal Medicine, Volume 31, p. 1115-1118 (May 13, 2016), https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5023604/.
\972\ See Thomas Clifford, ``Provider Liability and Medical
Identity Theft: Can I Get Your (Insurance) Number?,'' Northwestern
Journal of Law & Social Policy, Volume 12, p. 45 (2016), https://scholarlycommons.law.northwestern.edu/njlsp/vol12/iss1/2/.
\973\ Id.
\974\ Id.
---------------------------------------------------------------------------
Breaches of ePHI maintained by health care systems can also pose a
threat to the medical well-being of affected individuals. Cyberattacks
on health care organizations can include the deployment of malware that
compromises the function of both internal and external medical devices.
Such software can alter the dosages of sensitive medicines or shut down
devices while they are in use, thus affecting patient care.\975\ Some
of the medical devices that are vulnerable to malicious software
attacks include insulin pumps and cardiac implant devices.\976\ The
consequences of a cyberattack on such a medical device can be fatal.
---------------------------------------------------------------------------
\975\ See ``Assessing resilience of hospitals to cyberattack,''
supra note 130; see also Ashley Carman, `` `MEDJACK' tactic allows
cyber criminals to enter healthcare networks undetected,'' SC Media
(June 4, 2015) (``Medjack'' means a medical device hijack that
attackers use to exploit outdated and unpatched medical devices),
https://www.scmagazine.com/news/medjack-tactic-allows-cyber-criminals-to-enter-healthcare-networks-undetected.
\976\ See ``New Dangers in the New World: Cyber Attacks in the
Healthcare Industry,'' supra note 135.
---------------------------------------------------------------------------
Cyberattacks on relevant electronic information systems also hinder
the efficiency of hospitals and limit the quality of care provided to
patients. Breaches of relevant electronic information systems
negatively affect the routine functions of health care organizations.
They can affect the availability of ePHI and relevant electronic
information systems and redirect critical resources from patient care
to addressing the cybersecurity attack. A 2020 cyberattack on a large
covered entity disrupted communication and clinician access to medical
records, including to individualized chemotherapy plan templates and
tools for communicating during treatment preparation and delivery.\977\
In the first week following the attack, the hospital's ability to
provide critical outpatient care was reduced by 40 percent and infusion
visit volume decreased by 52 percent. Many patients had to be
transferred to other sites to minimize delays in receiving critical
medications. The effects of this data breach are not unique to this
provider. There is evidence that cyberattacks on health care
organizations decrease the number of patients they are able to treat in
a given day and staff utilization.\978\ Decreases in efficiency and
number of treated patients also cause health care facilities to lose
revenue because of their inability to provide care during a
cybersecurity event.
---------------------------------------------------------------------------
\977\ See Steven Ades, et al., ``Cancer Care in the Wake of a
Cyberattack: How to Prepare and What to Expect,'' JCO Oncology
Practice, Volume 18, p. 23-24 (Aug. 2, 2021), https://pubmed.ncbi.nlm.nih.gov/34339260/.
\978\ See ``Assessing resilience of hospitals to cyberattack,''
supra note 130.
---------------------------------------------------------------------------
Similar to the effects of breaches of ePHI on individuals, health
care organizations and facilities also experience reputational and
financial impacts because of cybersecurity attacks. Hospitals can lose
the community's trust and be subject to lawsuits from individuals whose
data was compromised.\979\ Organizations that experience cybersecurity
attacks can experience reputational harm and other monetary costs, such
as those associated with providing breach notifications, paying fines
to regulators and damages to individuals, and providing credit
monitoring and identity theft-related services.\980\ The harm to an
organization's reputation is difficult to quantify, but it can also
affect the quality of care administered to individuals.\981\ Privacy
and security of ePHI are paramount to individuals feeling safe and at
ease sharing their IIHI with clinicians. Security breaches can
negatively impact a patient's confidence in a health care organization
if they believe their information and privacy may be compromised. This
can cause them to delay seeking treatment or
[[Page 1003]]
withhold information from health care practitioners, ultimately
compromising the decision-making capacity of their health care provider
to administer the best quality of care.\982\ Decreasing the number and
scope of health care breaches would reduce the harms of such breaches
and would be a significant benefit of the proposals in the NPRM.
---------------------------------------------------------------------------
\979\ See Mohammed Alkinoon, et al., ``Measuring Health Care
Data Breaches,'' Information Security Applications, Volume 13009, p.
265-277 (Aug. 11, 2021), https://dl.acm.org/doi/10.1007/978-3-030-89432-0_22.
\980\ See ``The Big Phish: Cyberattacks Against U.S. Healthcare
Systems,'' supra note 971, p. 1115-1118.
\981\ See ``Health Records Database and Inherent Security
Concerns: A Review of the Literature,'' supra note 177.
\982\ Id.; see also Victoria Kisekka, et al., ``The
Effectiveness of Health Care Information Technologies: Evaluation of
Trust, Security Beliefs, and Privacy as Determinants of Health Care
Outcomes,'' Journal of Medical Internet Research, Volume 20 (Apr.
11, 2018), https://pubmed.ncbi.nlm.nih.gov/29643052/.
---------------------------------------------------------------------------
5. Comparison of Benefits and Costs
Key inputs to the estimation of costs of this proposed rule include
the numbers of regulated entities and health plan sponsors. The
Department has not previously quantified the costs of Security Rule
compliance for health plan sponsors because the existing requirements
are for plan documents to require such sponsors to implement
administrative, physical, and technical safeguards, but not necessarily
to comply with the specific requirements of the Security Rule.
Therefore, the proposed requirement to comply with the proposed changes
to the Security Rule, along with the number of affected plan sponsors
(approximately 740,000), results in a significant increase in overall
cost estimates compared to the existing rule. The benefits of improved
security for ePHI accrue to individuals, regulated entities, and health
plan sponsors and are significant. The Department has discussed the
benefits above.
The Department seeks to reduce the risk and mitigate the effects of
breaches of ePHI and related information systems through the proposals
included in this NPRM. Because the frequency and magnitude of
cybersecurity events are inherently difficult to predict, we chose to
conduct a break-even analysis in lieu of a cost savings analysis. The
Department solicits comments with any information and data on the
incidence and negative consequences of cybersecurity breaches.
The Department examined two different data points: the annual
number of individuals affected by health care breaches, and the annual
number of large breaches. Additionally, the Department considered a
high and a low baseline based on the number of breaches and affected
individuals per year. The Department calculated the high baseline as
the average of the three highest values in the 6 years of available
data (2018 to 2023, shown in table 8), and the low baseline as the
average of the three lowest values.
---------------------------------------------------------------------------
\983\ For this analysis, a record is the ePHI of one individual.
Table 8--Data on Breaches of ePHI
----------------------------------------------------------------------------------------------------------------
Affected individuals for Cost \b\ per record
Breach years large breaches \a\ \983\
----------------------------------------------------------------------------------------------------------------
2018...................................................... 12,493,549 $488
2019...................................................... 38,732,966 504
2020...................................................... 37,641,403 476
2021...................................................... 37,182,558 502
2022...................................................... 41,747,613 477
2023...................................................... 113,173,613 463
----------------------------------------------------------------------------------------------------------------
Number of large breaches Cost per breach
(500+ individuals)
----------------------------------------------------------------------------------------------------------------
2018...................................................... 302 12,012,809
2019...................................................... 408 7,582,508
2020...................................................... 656 8,273,537
2021...................................................... 609 10,241,897
2022...................................................... 626 10,468,138
2023...................................................... 725 10,930,000
----------------------------------------------------------------------------------------------------------------
\a\ The numbers of affected individuals and numbers of large breaches are contained in the Reports to Congress
on Breaches of Unsecured Protected Health Information for years 2018-2022, https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/reports-congress/index.html. Data for 2023 is contained in OCR's breach
portal, ``Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,''
Office for Civil Rights, U.S. Department of Health and Human Services, https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.
\b\ The cost per record and cost per breach are based on estimates for health care breaches from the annual IBM
Security and Ponemon Institute Costs of a Data Breach Reports for years 2018-2023. See ``Cost of a Data Breach
Report 2023,'' IBM Security, p. 10, 13 (July 24, 2023), available at https://www.ibm.com/reports/data-breach.
Because only general breach costs were available for the 2020-2023 period, the Department adjusted those by
multiplying them by the average of the ratios of health care-specific to overall breach costs for the years
for which both data points were available (2018, $408/$148 and 2019, $429/$150). All dollar values were
converted to 2023 dollars using the seasonally adjusted GDP Implicit Price Deflator, https://fred.stlouisfed.org/series/GDPDEF/.
The high baseline used 669 breaches and a total of 71 million
individuals affected, and the low baseline used 440 breaches and 29
million individuals affected.\984\ The high baseline represents years
with higher incidence of breaches, whereas the low baseline represents
years with lower incidence.
---------------------------------------------------------------------------
\984\ See ``Annual Report to Congress on Breaches of Unsecured
Protected Health Information for Calendar Year 2022,'' supra note
213, p. 9 (2023); ``December 2023 Healthcare Data Breach Report,''
supra note 960.
---------------------------------------------------------------------------
For each data point, the Department calculated the number of
breaches or affected individuals by which the affected universe would
have to decrease for the proposed rule to fully offset the annualized
costs of regulated entities.\985\ Table 9 and the discussion that
follows analyses the costs and cost savings based on the number of
individuals affected by breaches in a year and the cost per
individual's ePHI or medical record.
---------------------------------------------------------------------------
\985\ The break-even calculations presented here only include
regulated entities because breach data is not available for health
plan sponsors. Including sponsors and assuming they have the same
rate of breaches would result in a similar break-even point in terms
of percent decrease from baseline.
[[Page 1004]]
Table 9--Break-Even Thresholds by Number of Affected Individuals
--------------------------------------------------------------------------------------------------------------------------------------------------------
Break-even
Affected Regulated entities Unit cost (per threshold Percent decrease
Baseline individuals NPRM costs individual (NPRM cost / (threshold /
record) unit cost) affected) x 100
--------------------------------------------------------------------------------------------------------------------------------------------------------
High............................................................. 64,551,397 $2,251,258,305 $498 4,521,423 7
Low.............................................................. 29,006,854 16.4
--------------------------------------------------------------------------------------------------------------------------------------------------------
The analysis in table 9 suggests that this NPRM would break even
(cost savings would match monetized costs incurred) if the number of
affected individuals is reduced by approximately 4.5 million. In years
with a high incidence of breaches, this would be a reduction of
approximately 7 percent, and in low-incidence years this would be a
decrease of 16.4 percent. Thus, if the proposed changes in the NPRM
reduce the number of affected individuals by 7 to 16 percent, the rule
would pay for itself. Alternatively, the same cost savings may be
achieved by lowering the cost per affected individual's ePHI by 7
percent ($35) and 16 percent ($82), respectively.
Table 10 analyzes the potential cost savings for regulated entities
based on the annual number of large breaches of ePHI and the cost per
breach, as shown below.
Table 10--Break-Even Thresholds by Number of Large Breaches
--------------------------------------------------------------------------------------------------------------------------------------------------------
Break-even
NPRM cost for Unit cost (per threshold Percent decrease
Baseline Breaches regulated entities breach) (NPRM cost / (threshold /
unit cost) breaches) x 100
--------------------------------------------------------------------------------------------------------------------------------------------------------
High............................................................. 669 $2,251,258,305 $11,136,982 202 30.1
Low.............................................................. 440 58.9
--------------------------------------------------------------------------------------------------------------------------------------------------------
In table 10, the Department assumes that the average cost per
breach in industry reports ($11.1 million, calculated as the average of
the three highest values in table 9, adjusted for inflation) refers to
large breaches of ePHI . The analysis in table 10 suggests that the
NPRM would break even if the annual number of large breaches is reduced
by approximately 202. In high-incidence years, this would be a
reduction of approximately 30 percent, and in low-incidence years, this
would be a decrease of 59 percent. Alternatively, the same cost savings
may be achieved by lowering the cost per breach by 30 percent ($3.4
million) and 9 percent ($6.6 million), respectively.
B. Regulatory Alternatives to the Proposed Rule
The Department welcomes public comment on any benefits or drawbacks
of the following alternatives it considered, but did not propose, while
developing this proposed rule. We also request comment on whether the
Department should reconsider any of the alternatives considered, and if
so, why.
No Changes to the Security Rule
We considered not proposing revisions to the Security Rule.
However, the Department believes that not revising the Security Rule
would result in continued increases in both the number and size of
breaches. Such increases would result in an exponential increase in
costs as shown in table 8 above. If the modifications to the Security
Rule result in even modest improvements to the security of ePHI, the
reduction in the number and/or size of breaches would reduce the
overall costs associated with breaches, including the costs of
mitigating harm resulting from such breaches.
Email Security
The Department considered proposing a separate standard for
regulated entities to secure email transmissions. In the Department's
Cybersecurity Performance Goals,\986\ the Department identifies email
security as an essential goal for reducing risk from common email-based
threats such as email spoofing, phishing, and fraud. Therein, the
Department points to basic email protection controls identified in the
Health Industry Cybersecurity Practices, such as spam/virus checking
and real-time deny lists, as well as strategies that may be deployed
across small, medium, and large organizations, including MFA for email
access, email encryption, workforce education, and advance tooling
(e.g., URL click protection via analytics, attachment sandboxing).\987\
---------------------------------------------------------------------------
\986\ ``Cybersecurity Performance Goals,'' supra note 18.
\987\ Id.
---------------------------------------------------------------------------
The Department is aware of the threat that email poses to the
information systems of regulated entities and to the confidentiality,
integrity, and availability of ePHI.\988\ However, the Department
believes that it is important that the Security Rule remain technology-
neutral and that the security measures we propose in this NPRM apply to
a regulated entity's information systems broadly, including email
programs. For example, in this NPRM, the Department proposes to require
regulated entities to encrypt all ePHI at rest and in transit and
proposes a transmission security standard in which regulated entities
would be required to deploy technical controls to guard against
unauthorized access to ePHI that is being transmitted over an
electronic communications network.\989\ Therefore, the Department
believes it is unnecessary to promulgate a separate standard for email
security. Because the other technical controls, such as encryption and
MFA, are already incorporated into the requirements that would protect
relevant electronic information systems, the Department believes that
adopting a separate secure email standard would duplicate costs without
creating a net benefit.
---------------------------------------------------------------------------
\988\ According to the 2021 Verizon Data Breach Investigations
Report, ``phishing was `present in 36% of breaches (up from 25% last
year);' [and] 23% of malware was delivered through email.'' See
``Technical Volume 2: Cybersecurity Practices for Medium and Large
Healthcare Organizations,'' Cybersecurity Practice #1: Email
Protection Systems, HHS Healthcare & Public Health Sector
Coordinating Council, p. 13 (2023), https://405d.hhs.gov/Documents/tech-vol2-508.pdf (citing a 2021 Verizon Data Breach Investigations
Report).
\989\ See proposed 45 CFR 164.312(b)(2) and (g).
---------------------------------------------------------------------------
[[Page 1005]]
Additionally, the Department considered whether to heighten the
existing expectation \990\ for regulated entities to inform individuals
before transmitting ePHI to the individual via unencrypted email in
response to a request for access under 45 CFR 164.524 by this means. We
considered whether to require such notification for different types of
requests, such as different categories of PHI (e.g., billing, lab
results, etc.), determining whether the individual had already received
such notice, or providing notification upon each disclosure. Instead,
the Department has proposed to clarify that notification must be
provided for each request made by the individual under the individual
right of access at 45 CFR 164.524 for their ePHI to be transmitted via
unsecure email. We believe that requiring a regulated entity to
determine whether the individual had already received such notification
would be more burdensome than incorporating the notification into the
access request process, and instead, have proposed. We estimate that
this could increase burdens for providing access via unsecure means by
approximately one minute per request of this type. We lack data to
estimate the number of requests for access via unsecure means.
---------------------------------------------------------------------------
\990\ See ``Individuals' Right under HIPAA to Access their
Health Information 45 CFR 164.524,'' What is the liability of a
covered entity in responding to an individual's access request to
send the individual's PHI to a third party?, Office for Civil
Rights, U.S. Department of Health and Human Services, https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.
---------------------------------------------------------------------------
Small and Rural Health Care Providers
Consistent with the requirement that the Secretary adopt security
standards that take into account the needs and capabilities of small
health care providers and rural health care providers,\991\ the
Department considered excepting small and rural health care providers
from the requirement to perform penetration testing at proposed 45 CFR
164.308(h)(2)(iii) to lower anticipated costs of the rule for such
providers. The Department estimates that approximately 90 percent of
providers are small (based on revenue). Thus, the estimated cost
reduction from this exemption (as compared to the proposed requirement
for all regulated entities), would be approximately $266,389,139
[822,600 x .9 x 3 hours x $119.94 wage of an information security
analyst] annually. While the Department is aware of the cost
implications of this requirement for small and rural health care
providers, we also believe that penetration testing is a critical
component of managing vulnerability to cyberthreats across the health
care sector. Additionally, we believe that setting different
requirements for cybersecurity for small and rural health care
providers would lead such health care providers to believe that they
can limit their investment in cybersecurity. Given that a significant
amount of health care is provided by small and rural health care
providers, limiting their investment in cybersecurity would create a
sizable gap in security protections. Such a gap has the potential to
increase such providers' attractiveness to cybercriminals.
---------------------------------------------------------------------------
\991\ 42 U.S.C. 1320d-2(d)(1)(A)(v).
---------------------------------------------------------------------------
The Department also considered proposing to permit small and rural
health care providers to adopt alternate compensating controls, in lieu
of the specified implementation specifications, to meet certain
standards. After careful consideration, the Department concluded that
it potentially could be just as costly to identify and adopt
compensating controls that are reasonable and appropriate for small and
rural health care practices. Small and rural health care providers
would likely need to either hire personnel or contract with
cybersecurity experts to identify potential compensating controls that
would meet the relevant standard and provide implementation support.
Accordingly, the Department declines to put forward such proposals at
this time.
The Federal Information Security Modernization Act
The Department considered the requirements of the Federal
Information Security Modernization Act (FISMA) \992\ and whether
compliance with FISMA by Federal agencies that are also regulated
entities would be comparable to meeting the proposals in this NPRM.
FISMA requires each Federal agency to develop, document, and implement
an agency-wide program to provide information security for the
information and information systems that support the operations and
assets of the agency, including those provided or managed by another
agency, contractor, or other source.\993\ After careful consideration,
the Department does not believe that a regulated entity's compliance
with FISMA would necessarily ensure compliance with all applicable
proposed requirements in this NPRM because FISMA's requirements and the
Security Rule's requirements are designed to serve different purposes.
FISMA primarily focuses on securing Federal information systems, while
the Security Rule applies specifically to ePHI. This NPRM contains
specific proposed requirements, not found in FISMA, which are tailored
to ensure the confidentiality, integrity, and availability of ePHI.
Therefore, although the Department believes that FISMA requirements are
consistent with those in the Security Rule and the proposals in this
NPRM, we decline to propose that compliance with FISMA requirements
would be a comparable alternative to compliance with the proposals in
this NPRM. Instead, we believe that FISMA requirements complement the
Security Rule and the proposed requirements and will facilitate the
ability of regulated entities that are also subject to FISMA to fulfill
their compliance with the HIPAA Rules.
---------------------------------------------------------------------------
\992\ Public Law 113-283 (Dec. 18, 2014) (codified at 44 U.S.C.
3551 et seq.).
\993\ Id.
---------------------------------------------------------------------------
Modifications to the Definition of ``Information System''
The Department considered proposing additional modifications to the
definition of ``information system.'' The Security Rule currently
defines the term ``information system'' as an interconnected set of
information resources under the same direct management control that
shares common functionality and includes hardware, software,
information, data, applications, communications, and people.\994\ This
definition is based on the definition of ``general support system'' or
``system'' in the appendix to the 1996 version of OMB Circular A-130,
Security of Federal Automated Information Systems.\995\ We considered
proposing to remove the phrase ``under the same direct management
control'' as a potential way to clarify the application of the
definition to cloud-based computing. Cloud computing applications play
an important role in health care today. For example, many health care
providers have implemented cloud-based electronic health records (EHRs)
and practice management systems. These applications are used to create,
receive, maintain, and transmit ePHI, and as such, should be included
as components of a covered entity's relevant electronic information
system, a term which is based upon the term ``information system.''
After careful consideration, we have decided to retain the phrase
``under the same direct
[[Page 1006]]
management control'' and instead clarify in the preamble how the
definition of ``information system'' applies in cloud computing
environments. The Department also requests comment on the definition of
``information system'' and the extent of control a regulated entity has
with respect to applications in cloud computing environments.
---------------------------------------------------------------------------
\994\ 45 CFR 164.304 (definition of ``Information system'').
\995\ ``Managing Information as a Strategic Resource,'' Circular
No. A-130, Management of Federal Information Resources, Appendix
III, Security of Federal Automated Information Resources, Office of
Management and Budget, Executive Office of the President (Feb. 8,
1996), https://georgewbush-whitehouse.archives.gov/omb/circulars/a130/a130.html.
---------------------------------------------------------------------------
We also considered proposing to adopt the definition of
``information system'' in the Paperwork Reduction Act of 1995 (PRA) and
the current operative version of OMB Circular A-130.\996\ The PRA and
OMB Circular A-130 define ``information system'' as ``a discrete set of
information resources organized for the collection, processing,
maintenance, use, sharing, dissemination, or disposition of
information.'' The Department declined to adopt this definition because
the existing definition in the Security Rule based on the definition of
``system'' in the 1996 version of OMB Circular A-130 more accurately
reflects the typical components of an information system and the full
extent of resources that are addressed by the Security Rule.
Additionally, the definition of ``information system'' in the PRA and
current operative version of OMB Circular A-130 contains some terms
that are defined by the HIPAA Rules and some that are not. As a result,
adopting this definition would require the Department to propose
definitions to such additional terms and to ensure that the manner in
which the terms with existing definitions are used is consistent with
those existing definitions, and we are concerned that such change could
cause significant confusion for regulated entities.
---------------------------------------------------------------------------
\996\ Public Law 104-13, 109 Stat. 166 (May 22, 1995) (codified
at 44 U.S.C. 3502(8)) (definition of ``information system''); see
also ``Managing Information as a Strategic Resource,'' Circular No.
A-130, Office of Management and Budget, Executive Office of the
President, p. 31 (Jul. 28, 2016), (definition of ``information
system'') https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/circulars/A130/a130revised.pdf.
---------------------------------------------------------------------------
We do not believe that either of the alternative definitions
considered would have generated a quantifiable change in costs because
the alternatives would be clarifications to existing requirements and
would not have changed the scope of the Security Rule's applicability.
Exception From Multi-Factor Authentication (MFA) Requirement
The Department considered proposing an exception to the MFA
authentication requirement that would permit regulated entities in the
future to adopt other technologies, in lieu of MFA, that might offer a
more secure method of authenticating user identity.\997\ Based on
discussions with cybersecurity experts, the Department believes that
MFA is likely to remain the most secure method for authenticating user
identity in future years. It may take different forms, but it will
still, at its core, meet the definition of MFA proposed in this NPRM
for the foreseeable future.\998\
---------------------------------------------------------------------------
\997\ Proposed 45 CFR 164.312(f)(2)(ii).
\998\ 45 CFR 164.304 (proposed definition of ``Multi-factor
authentication'').
---------------------------------------------------------------------------
While the Department acknowledges that technology will continue to
evolve, we are unable to predict when and whether future technology
will address identity verification and exceed the level of protection
offered by MFA. This uncertainty renders us unable to articulate
requirements specific enough to justify a purposeful exception. Because
of the uncertainty surrounding new technologies, we are also unable to
estimate costs of adopting this alternative. Our current view is that
proposing and codifying such an exception would be premature, but we
will revisit the proposed specific requirement for MFA, if adopted, and
reconsider the need for an exception should a more secure technology
emerge.
Transition for Business Associates and Group Health Plans
The Department considered requiring regulated entities to comply
with all of the proposals in this NPRM by the compliance date, rather
than proposing transition provisions for existing business associate
agreements or other contractual arrangements. Had the Department taken
that approach, we would have proposed that regulated entities update
all existing business associate agreements by the proposed compliance
date to comply with all applicable proposed requirements in this NPRM.
While the Department believes that many of the proposals in this NPRM
are consistent with the Security Rule as it currently exists, we are
also concerned that too many regulated entities are not currently
compliant with the Security Rule. Given the demonstrable increase in
breaches, we believe that it is more important for regulated entities
to first improve their cybersecurity posture by coming into compliance
with all applicable proposed requirements in this NPRM, if adopted.
Upon doing so, the Department anticipates that regulated entities will
be better positioned to evaluate their contractual needs and to modify
existing business associate agreements. For this reason, the Department
has proposed the transition provisions in proposed 45 CFR 164.318. Not
allowing for a transition period could have an opportunity cost whereby
regulated entities spend their limited time revising business associate
agreements instead of enhancing their cybersecurity posture. The
Department believes that this could result in duplicative costs because
some regulated entities may identify the need for additional changes to
business associate agreements after they have fully evaluated their
changed cybersecurity needs. The Department estimates that small
regulated entities may be more likely to experience that outcome
without a transition period, and thus the alternative of no transition
period would cause a potential one-time increase in costs of
$278,332,891 [(1,822,600 regulated entities x .9) x 1 hour x $169.68
lawyer hourly wage].
Relatedly, the Department considered proposing similar transition
provisions for group health plans and plan sponsors that would provide
these entities with additional time to update plan documents to align
with new proposed requirements in this NPRM, if adopted. However, the
Department believes that affected plans and plan sponsors would be able
to complete any necessary updates by the proposed compliance date. The
Department believes that updating plan documents is not as complex a
task as evaluating potential new contractual needs to meet business
associate obligations. Additionally, plan sponsors do not have Security
Rule obligations independent of plan documents, and thus would not be
obligated to implement the requirements proposed in this NPRM absent
updates to the plan documents. The result of a transition period for
updating plan documents would be merely to delay compliance with the
changed Security Rule requirements, and therefore, delay improvements
to their cybersecurity posture, not to reduce costs. Accordingly, we
are not proposing such transition provisions in this NPRM.
C. Regulatory Flexibility Act--Small Entity Analysis
The Department has examined the economic implications of this
proposed rule as required by the RFA. If a rule has a significant
economic impact on a substantial number of small entities, the RFA
requires agencies to analyze regulatory options that would reduce the
economic effect of the rule on small entities. As discussed in greater
detail below, this analysis concludes, and the Secretary proposes to
certify, that the proposed rule, if finalized, would not
[[Page 1007]]
result in a significant economic effect on a substantial number of
small entities.
For purposes of the RFA, small entities include small businesses,
nonprofit organizations, and small governmental jurisdictions. The Act
defines ``small entities'' as (1) a proprietary firm meeting the size
standards of the SBA, (2) a nonprofit organization that is not dominant
in its field, and (3) a small government jurisdiction of less than
50,000 population. The Department has determined that roughly 90
percent or more of all health care providers meet the SBA size standard
for a small business as shown in table 4 or are a nonprofit
organization. Therefore, the Department estimates that there would be
740,348 small entities affected by the proposals in this proposed
rule.\999\ The SBA size standard for health care providers ranges
between a maximum of $9 million and $47 million in annual receipts,
depending upon the type of entity, as shown in table 4, above.\1000\
---------------------------------------------------------------------------
\999\ 740,348 = 822,609 covered entities x .90.
\1000\ See ``Table of Small Business Size Standards,'' U.S.
Small Business Administration (Mar. 17, 2023), https://www.sba.gov/sites/sbagov/files/2023-06/Table%20of%20Size%20Standards_Effective%20March%2017%2C%202023%20%282%29.pdf.
---------------------------------------------------------------------------
With respect to health insurers, the SBA size standard is a maximum
of $47 million in annual receipts, and for pharmacy benefits and
clearinghouses it is $45.5 million.\1001\ While some insurers are
classified as nonprofit, it is possible they are dominant in their
market. For example, a number of Blue Cross/Blue Shield insurers are
organized as nonprofit entities; and yet, they dominate the health
insurance market in the States where they are licensed.\1002\
---------------------------------------------------------------------------
\1001\ Id.
\1002\ ``Market Share and Enrollment of Largest Three Insurers--
Large Group Market,'' Kaiser Family Foundation (2019), https://www.kff.org/other/state-indicator/market-share-and-enrollment-of-largest-three-insurers-large-group-market/?currentTimeframe=0&sortModel=%7B%22colId%22:%22Location%22,%22sort%22:%22asc%22%7D.
---------------------------------------------------------------------------
With respect to business associates, they provide a wide range of
services for covered entities, including computer infrastructure,
clearinghouse activities, leased office equipment, and professional
services, such as legal, accounting, business planning, and marketing.
The SBA size thresholds for these industries ranges from $15.5 million
for lawyers to $47 million for clearinghouses.\1003\
---------------------------------------------------------------------------
\1003\ See ``Table of Small Business Size Standards,'' supra
note 1000.
---------------------------------------------------------------------------
For the reasons stated below, the Department does not expect that
the cost of compliance would be significant for small entities. Nor
does the Department expect that the cost of compliance would fall
disproportionately on small entities. Although many of the regulated
entities affected by the proposals in this proposed rule are small
entities, they would not bear a disproportionate cost burden compared
to the other entities subject to the rule. The projected total costs
are discussed in detail in the RIA. The Department does not view this
as a substantial burden because the result of the changes would be
annualized costs per regulated entity of approximately $1,235 [= $2.3
billion \1004\/1,822,600 regulated entities]. The per-entity costs
represent the costs per establishment. As a result, smaller entities'
costs are lower because they have fewer establishments. Larger
regulated entities (i.e., firms) that have multiple facilities (i.e.,
establishments) would experience higher costs than the average cost per
establishment because each firm would need to apply the proposals to
all of their establishments. In the context of the RFA, HHS generally
considers an economic impact exceeding 3 percent of annual revenue to
be significant, and 5 percent or more of the affected small entities
within an identified industry to represent a substantial number.
---------------------------------------------------------------------------
\1004\ This figure is rounded and represents annualized costs
discounted at a 2 percent rate. The actual figure is $2,251,258,305.
---------------------------------------------------------------------------
More than 5 percent of the small covered entities listed under the
NAICS codes in table 4 are one-establishment firms with fewer than five
employees,\1005\ so the analysis must determine how the effects of the
quantified costs on one-establishment firms compare to their revenues.
As explained above, the cost for a one-establishment firm is $1,235, so
only small firms whose revenues are below $41,167 [=$1,235/0.03] would
experience an effect exceeding 3 percent.
---------------------------------------------------------------------------
\1005\ SUSB 2017 reports average revenue per firm by employment
size. The size categories begin with less than 5 employees followed
by 5 to 10 employees, and so on, with the largest categories
representing firms with 2,500 to 4,999 employees and 5,000 or more
employees). ``2017 [Statistics of U.S. Businesses] Annual Data
Tables by Establishment Industry,'' (May 2021), https://www.census.gov/data/tables/2017/econ/susb/2017-susb-annual.html. We
inflated these revenues to 2021 dollars using the GDP deflator to
estimate average revenues in each employment class in 2021 because
that is the latest year for which data is reported. See ``2021
[Statistics of U.S. Businesses] SUSB Annual Data Tables by
Establishment Industry,'' supra note 947. We then concluded that
more than 5 percent of the firms whose revenues fall below the SBA
thresholds (see table 4) belong to the ``fewer than 5 employees''
category and operate a single establishment.
---------------------------------------------------------------------------
Among the NAICS codes for health care providers, the small firms
with the lowest revenues are one-establishment HMO [Health Maintenance
Organization] Medical Centers (NAICS 621491) with fewer than five
employees, which had an estimated average yearly revenue in 2021 of
$108,000. Residential Intellectual and Developmental Disability
Facilities (NAICS 623210) had the second lowest revenues for one-
establishment firms with fewer than five employees, with $180,000.
Offices of Mental Health Practitioners (NAICS 621330) have the third
lowest revenues for one-establishment firms with fewer than five
employees, with $189,000. Thus, the Department believes that almost all
regulated entities have annual revenues that exceed these amounts.
The Department acknowledges that there may be very small firms--
namely firms without employees--whose revenues are below $41,167. We
believe that such firms would comply with the regulation by purchasing
services from software and web-hosting companies whose costs may
increase as a result of the proposed changes. Such software and web-
hosting companies would be business associates, and thus costs to them
are already accounted for. We believe that, to the extent that these
business associates decide to recover their minor cost increases by
raising the prices of the services sold to non-employer firms, these
incremental costs passed through to their small-firm customers would be
negligible because they will be spread among many non-employer firms.
The Department has separately analyzed the effects of the NPRM on
health plan sponsors and does not view the projected costs as a
significant burden because the proposed changes would result in
annualized costs per plan sponsor of approximately $6,133
[=$4,552,995,816/742,411 health plan sponsors]. The quantified impact
of $6,133 per health plan sponsor would only apply to those sponsors
whose annual revenue is $204,433 or less.\1006\ The Department believes
there are few, if any, group health plan sponsors with annual revenues
below this amount because the average revenue of a U.S. business with
1-4 employees is $387,000 \1007\ and employers with 0-1 employees are
unlikely to sponsor a group health plan.
---------------------------------------------------------------------------
\1006\ $6,133 is 3 percent of $204,433.
\1007\ ``Average Small Business Revenue: What To Know,'' Fora
Financial (Jan. 11, 2023), https://www.forafinancial.com/blog/small-business/average-small-business-revenue/.
---------------------------------------------------------------------------
Accordingly, the Department believes that this proposed rule, if
adopted, would be unlikely to affect a substantial
[[Page 1008]]
number of small entities that meet the RFA threshold. Thus, this
analysis concludes, and the Secretary proposes to certify, that the
NPRM would not result in a significant economic effect on a substantial
number of small entities.
HIPAA requires the Department to consider the needs and
capabilities of small and rural health care providers.\1008\ As we
explained in our 2003 analysis of the effect of the Security Rule on
small and rural health care providers, the scalability provisions
preclude the need to precisely define those categories.\1009\ We have
long considered the effect of our rules on small businesses in the
Small Entity Analysis discussed above. However, because of the breadth
of changes proposed in this NPRM, the Department has considered more
closely how it would affect rural health care providers. There are
approximately 2,000 rural hospitals,\1010\ comprising nearly 30 percent
of all hospitals [= 2,057/7,465],\1011\ and the Department estimates
approximately 7 to 8 percent of all health care providers operate in
rural areas (counties or micropolitan areas with fewer than 50,000
inhabitants). See Regulated Entities Affected in Section V.A.2.
Baseline Conditions, above.
---------------------------------------------------------------------------
\1008\ 42 U.S.C. 1320d-2(d).
\1009\ See 68 FR 8334, 8341 (Feb. 20, 2003).
\1010\ See ``Fact Sheet: Biden-Harris Administration Bolsters
Protections for Americans' Access to Healthcare Through
Strengthening Cybersecurity,'' supra note 306. See also table 4
above, SBA size threshold for hospitals.
\1011\ See ``2021 [Statistics of U.S. Businesses] SUSB Annual
Data Tables by Establishment Industry,'' supra note 947 (count of
hospitals).
---------------------------------------------------------------------------
Because rural health care providers are more likely to be small
businesses, they would be affected in a manner similar to small
entities, as demonstrated in the Small Entity Analysis above. Likewise,
to the extent that Tribal health care providers are in rural areas,
which many are,\1012\ our analysis of the effects on rural health care
providers generally also applies. However, Tribal health providers have
the benefit of access to centralized supportive services for health IT
and EHR adoption, which other rural providers may lack.\1013\ A primary
barrier to both adoption of health information technology (health IT)
and deployment of cybersecurity safeguards in rural communities is
limited access to high-speed internet. Rural health care providers,
such as hospitals, have adopted EHRs at a lower rate than non-rural
hospitals,\1014\ and thus may also have fewer electronic information
systems that are subject to the Security Rule requirements, which could
ease some burdens of compliance. However, as EHR adoption has increased
in rural hospitals,\1015\ so too have the risks of cybersecurity
attacks.\1016\ Rural health care providers are more likely to have
limited resources to update legacy information technology (IT) systems,
implement new or changed regulatory requirements, and respond to large
breaches. Additionally, the health IT workforce is more limited in
rural areas, which may affect the ability of rural health care
providers to access in-person technical assistance. Because most rural
hospitals are ``located more than 35 miles from another hospital,''
responding to cyberattacks may be more challenging.\1017\ We request
comment on the burdens these proposals would impose on rural health
care providers, including rural hospitals.
---------------------------------------------------------------------------
\1012\ The Indian Health Service funds a ``network of over 600
hospitals, clinics, and health stations on or near Indian
reservations in service areas that are rural, isolated, and
underserved.'' ``Justification of Estimates for Appropriations
Committees, Fiscal Year 2025'' Indian Health Service, U.S.
Department of Health and Human Services, p. CJ-39 (Mar. 5, 2024).
\1013\ See id. at p. CJ-63-75.
\1014\ See ``Telehealth and Health Information Technology in
Rural Healthcare,'' Rural Health Information Hub, https://www.ruralhealthinfo.org/topics/telehealth-health-it#challenges-for-rural-communities.
\1015\ See ``Percent of Hospitals, By Type, that Possess
Certified Health IT,'' supra note 298.
\1016\ Kat Jercich, ``Rural hospitals are more vulnerable to
cyberattacks--here's how they can protect themselves,'' supra note
295.
\1017\ See ``Fact Sheet: Biden-Harris Administration Bolsters
Protections for Americans' Access to Healthcare Through
Strengthening Cybersecurity,'' supra note 306.
---------------------------------------------------------------------------
Rural health care providers and other regulated entities can avail
themselves of grants and incentives to improve broadband access and
adoption of health IT.\1018\ For cybersecurity in particular, the White
House, in partnership with private companies, announced the
availability of direct assistance to rural health care providers on
cybersecurity in the form of grants, discounts, and technical
advice.\1019\ Additionally, CISA has compiled a list of free services
and tools available to regulated entities from private and public
sector entities. CISA also has published, in partnership with the Joint
Cyber Defense Collaborative, a list of cybersecurity resources
especially focused on high-risk communities.\1020\ And the Advanced
Research Projects Agency for Health announced plans to invest $50
million to develop an autonomous solution for addressing cyberthreats
to assist hospitals in defending their information systems.\1021\
---------------------------------------------------------------------------
\1018\ Hannah Neprash, et al., ``What happens to rural hospitals
during a ransomware attack? Evidence from Medicare data,'' The
Journal of Rural Health (Mar. 17, 2024), https://pubmed.ncbi.nlm.nih.gov/38494590/. For information about grants and
incentives available for improving broadband access and adoption of
health IT, see, e.g., ``Funding Programs,'' BroadbandUSA, National
Telecommunications and Information Administration, U.S. Department
of Commerce, https://broadbandusa.ntia.doc.gov/funding-programs;
``Rural Health Care Program,'' Federal Communications Commission,
https://www.fcc.gov/general/rural-health-care-program.
\1019\ See ``Fact Sheet: Biden-Harris Administration Bolsters
Protections for Americans' Access to Healthcare Through
Strengthening Cybersecurity,'' supra note 306.
\1020\ See, e.g., ``Free Cybersecurity Services and Tools,''
supra note 313; ``Cybersecurity Resources for High-Risk
Communities,'' supra note 313.
\1021\ See ``Fact Sheet: Biden-Harris Administration Bolsters
Protections for Americans' Access to Healthcare Through
Strengthening Cybersecurity,'' supra note 306; see also ``UPGRADE,
Universal Patching and Remediation for Autonomous Defense,''
Advanced Research Projects Agency for Health (May 20, 2024), https://arpa-h.gov/research-and-funding/programs/upgrade.
---------------------------------------------------------------------------
Cybersecurity is as essential for small and rural health care
providers and their business associates, as it is for large and urban
regulated entities. The seamless flow of data and increased
connectivity means that threats to one health care provider do not
affect only that one health care provider, regardless of size or
location. The effects on patient care may be greater in rural
environments where fewer alternatives exist if care is delayed or
denied as a result of a cyberattack or malfunction.\1022\ As discussed
in the preamble, the factors described at 45 CFR 164.306(b)(2) provide
the flexibility for small and rural providers, in particular, to adopt
security measures that are reasonable and appropriate for their
circumstances.
---------------------------------------------------------------------------
\1022\ ``What happens to rural hospitals during a ransomware
attack? Evidence from Medicare data,'' supra note 1018.
---------------------------------------------------------------------------
D. Executive Order 13132--Federalism
As required by E.O. 13132 on Federalism,\1023\ the Department has
examined the provisions in the proposed regulation for their effects on
the relationship between the Federal Government and the States. E.O.
13132 establishes certain requirements that an agency must meet when it
promulgates a proposed rule (and subsequent final rule) that imposes
substantial direct requirement costs on State and local governments,
preempts State law, or otherwise has federalism implications. In the
Department's view, the proposed rule would not have any federalism
implications.
---------------------------------------------------------------------------
\1023\ 64 FR 43255 (Aug. 4, 1999).
---------------------------------------------------------------------------
The federalism implications of the Security Rule were also assessed
as required by E.O. 13132 and published as part of the preambles to the
final rules on February 20, 2003 \1024\ and January
[[Page 1009]]
25, 2013.\1025\ Regarding preemption, HIPAA dictates the relationship
between State law and HIPAA regulatory requirements.\1026\ The Health
Information Technology for Economic and Clinical Health Act of 2009
(HITECH Act) provides that the HIPAA preemption provisions shall apply
to the HITECH Act provisions and requirements.\1027\ As explained by
the House report that accompanied the American Recovery and
Reinvestment Act of 2009, the HITECH Act would not only apply HIPAA's
preemption provisions to the HITECH Act requirements, but it would also
``preserve the HIPAA privacy and security standards to the extent that
they are consistent with'' the HITECH Act.\1028\
---------------------------------------------------------------------------
\1024\ 68 FR 8334, 8373 (Feb. 20, 2003).
\1025\ 78 FR 5566, 5686 (Jan. 25, 2013).
\1026\ 42 U.S.C. 1320d-7.
\1027\ Sec. 13421(a) of the HITECH Act; see also 45 CFR part
160, subpart B.
\1028\ See ``MAKING SUPPLEMENTAL APPROPRIATIONS FOR JOB
PRESERVATION AND CREATION, INFRASTRUCTURE INVESTMENT, ENERGY
EFFICIENCY AND SCIENCE, ASSISTANCE TO THE UNEMPLOYED, AND STATE AND
LOCAL FISCAL STABILIZATION, FOR THE FISCAL YEAR ENDING SEPTEMBER 30,
2009, AND FOR OTHER PURPOSES,'' Conf. Report to Accompany H.R. 1, p.
502 (Feb. 12, 2009).
---------------------------------------------------------------------------
A requirement, standard, or implementation specification adopted in
accordance with HIPAA and the HIPAA Rules supersedes any contrary
provision of State law, subject to certain exceptions.\1029\
Specifically, State law would be preempted under the Security Rule only
when (1) a regulated entity finds it impossible to comply with both
State and Federal requirements; or (2) the provision of State law
stands as an obstacle to accomplishing and executing the purposes and
objectives of the Administrative Simplification provisions or the
HITECH Act.\1030\ Although a few States (e.g., California and New York)
have promulgated or are in the process of promulgating regulations
pertaining to cybersecurity in health care that may be more stringent
than the Security Rule, the Department believes that a regulated entity
could comply with both sets of requirements by adhering to the more
stringent standard. Thus, in such cases, the State law would not be an
obstacle to the accomplishment and execution of HIPAA or the HITECH
Act.
---------------------------------------------------------------------------
\1029\ 42 U.S.C. 1320d-7(a); 45 CFR 160.203.
\1030\ See 45 CFR 160.202 (definition of ``Contrary'').
Preemption also applies if the provision of State law stands as an
obstacle to the accomplishment and execution of the full purposes
and objectives and purposes of sec. 264 of HIPAA. Sec. 264 of HIPAA
contains the provisions pertaining to the privacy of individually
identifiable health information.
---------------------------------------------------------------------------
The proposed modifications to the Security Rule would further the
Congressional intent to improve the Medicare and Medicaid programs by
the development of health information systems that are private and
secure. The Department's proposals promote the safety, efficiency, and
effectiveness of the health care system by refining the security
standards established by Congress and implemented in the 2003 and 2013
Final Rules. The statute contemplated that the security measures
adopted by all regulated entities, including State and local
governments, would evolve over time in accordance with the security
risks they face, and the NPRM proposals are in the nature of enhancing
these existing requirements. Thus, the Department does not believe that
the rule would impose substantial direct compliance costs on State and
local governments that are not required by statute.
The Department anticipates that the most significant direct costs
on State and local governments would be for conducting a Security Rule
compliance audit; notifying covered entities or business associates, as
applicable, upon activation of a contingency plan; notifying covered
entities of changes or termination of workforce members' access to
ePHI; deploying MFA; removing extraneous software; and penetration
testing; providing or obtaining verification of business associates'
compliance with technical safeguards; updating health plan documents;
updating policies and procedures; and updating workforce training.
However, the costs involved can be attributed to the statutory
requirements of the Administrative Simplification provisions of HIPAA
and would be similar in kind to those borne by non-government-operated
regulated entities, which the proposed RIA above addresses in detail.
In considering the principles in and requirements of E.O. 13132,
the Department believes that these proposed modifications to the
Security Rule would not significantly affect the rights, roles, and
responsibilities of the States and requests comment on this analysis.
E. Assessment of Federal Regulation and Policies on Families
Section 654 of the Treasury and General Government Appropriations
Act of 1999 \1031\ requires Federal departments and agencies to
determine whether a proposed policy or regulation could affect family
well-being. If the determination is affirmative, then the Department or
agency must prepare an impact assessment to address criteria specified
in the law. This proposed rule is expected to strengthen family well-
being because it would ensure a baseline of security measures for
individuals' PHI, and medical information and decisions based on that
information are at the heart of family decision making. If finalized,
the provisions in this proposed rule may be carried out only by the
Federal Government because it would modify Federal law on cybersecurity
in health care, ensuring that American families have confidence that
the privacy of their PHI is secured by consistent safeguards,
regardless of the State where they are located when health care is
provided. Such health care privacy and is vital for individuals who
seek or access health care.
---------------------------------------------------------------------------
\1031\ Public Law 105-277, 112 Stat. 2681-528 (Oct. 21, 1998)
(codified at 5 U.S.C. 601 note).
---------------------------------------------------------------------------
F. Paperwork Reduction Act of 1995
Under the PRA,\1032\ agencies are required to submit to OMB for
review and approval any reporting or recordkeeping requirements
inherent in a proposed or final rule and are required to publish such
proposed requirements for public comment. To fairly evaluate whether an
information collection should be approved by the OMB, section
3506(c)(2)(A) of the PRA requires that the Department solicit comment
on the following issues:
---------------------------------------------------------------------------
\1032\ Public Law 104-13, 109 Stat. 163 (May 22, 1995) (codified
at 44 U.S.C. 101 note).
---------------------------------------------------------------------------
1. Whether the information collection is necessary and useful to
carry out the proper functions of the agency.
2. The accuracy of the agency's estimate of the information
collection burden.
3. The quality, utility, and clarity of the information to be
collected.
4. Recommendations to minimize the information collection burden on
the affected public, including automated collection techniques.
The PRA requires consideration of the time, effort, and financial
resources necessary to meet the information collection requirements
referenced in this section. The Department solicits public comments on
its assumptions and burden estimates in this NPRM as summarized below.
In this RIA, the Department proposes to revise certain information
collection requirements associated with this NPRM and, as such, would
revise the information collection last prepared in 2024 and approved
under OMB control #0945-0003.\1033\ The proposed revisions to the
information collection describe all new and adjusted information
[[Page 1010]]
collection requirements for regulated entities pursuant to the
implementing regulation for HIPAA at 45 CFR parts 160 and 164, the
HIPAA Privacy, Security, Breach Notification, and Enforcement Rules
(``HIPAA Rules'').
---------------------------------------------------------------------------
\1033\ ``View ICR,'' supra note 940.
---------------------------------------------------------------------------
The estimated annual labor burden presented by the regulatory
modifications is 77,067,552 burden hours at a first-year cost of
$9,314,106,174. These figures, respectively, represent the sum of
37,781,637 new burden hours at a cost of $4,655,324,954 for compliance
by regulated entities and 39,285,915 new burden hours at a cost of
$4,658,781,219 for compliance by health plan sponsors.
The overall total burden for respondents to comply with the
information collection requirements of all of the HIPAA Privacy,
Security, and Breach Notification Rules, including new burdens
presented by proposed program changes, is estimated to be 925,144,023
burden hours at a cost of $109,085,104,674, plus $163,499,411 in
capital costs for a total estimated annual burden of $109,248,604,085,
after the effective date of the final rule. This estimate is based on a
total of 1,202,562,864 responses for a total of 2,565,011 respondents.
The total burden for the HIPAA Rules, including the changes proposed in
this NPRM, would result in a decrease of 28,838,213 burden hours and a
cost increase of $1,911,898,144, in comparison to the baseline in the
ICR associated with the 2024 Privacy Rule to Support Reproductive
Health Care Privacy.\1034\ This is the result of multiples changes,
such as decreasing burden hours for some existing requirements,
increasing the estimated number of covered entities, adding new
Security Rule requirements, and expanding the pool of respondents for
the Security Rule by adding requirements for health plan sponsors.
---------------------------------------------------------------------------
\1034\ Id.
---------------------------------------------------------------------------
Details describing the burden analysis for the proposals associated
with this RIA are presented below and explained further in the ICR
associated with the NPRM.
1. Explanation of Estimated Annualized Burden Hours
Below is a summary of the significant program changes and
adjustments proposed since the approved 2024 ICR; because the ICR
addresses regulatory burdens associated with the full suite of HIPAA
Rules, the changes and adjustments include updated data and estimates
for some provisions of the HIPAA Rules that are not affected by this
proposed rule. These program changes and adjustments form the bases for
the burden estimates presented in the ICR associated with this NPRM.
Adjusted Estimated Annual Burdens of Compliance
(1) Updating the number of covered entities.
(2) Updating hourly wage rates.
(3) Adjusting downward the number of estimated requests for an
exception to Federal preemption of State law to the prior baseline of 1
request per year.
(4) Adjusting downward the estimated hourly burden for regulated
entities to report security incidents (not breaches) from 20 hours per
monthly report to 10 hours per monthly report.
(5) Updating the number of research disclosures.
New Burdens Resulting From Program Changes
In addition to the adjustments above, the Department proposes to
add new annual estimated burdens as a result of program changes, as
follows:
(1) A burden of 2 hours for each regulated entity to conduct a
Security Rule compliance audit.
(2) A burden of 2 hours for each business associate (including each
subcontractor) to provide verification of compliance with technical
safeguards.
(3) A burden of .5 hours for each covered entity to obtain
verification of business associates' compliance with technical
safeguards.
(4) A burden of .083 hours for each business associate to obtain
verification of subcontractors' compliance with technical safeguards.
(5) A burden of 1 hour for each regulated entity to provide
notification to other regulated entities of workforce members'
termination of access to ePHI.
(6) A burden of 1.5 hours for each regulated entity to deploy MFA.
(7) A burden of 4.5 hours for each regulated entity to perform
network segmentation.
(8) A burden of .5 hours for approximately 76.56 percent of
regulated entities to disable unused ports and remove extraneous
software.
(9) A burden of 3 hours for each regulated entity to conduct
penetration testing.
(10) A burden of .5 hours for each regulated entity to notify
covered entities or business associates, as applicable, upon activation
of a contingency plan.
(11) A burden of .5 hours for each insurer and third-party
administrator to update health plan documents.
(12) A burden of 2 hours for each regulated entity to update the
content of its cybersecurity awareness and Security Rule training
program.
(13) A burden of 3.5 hours for each regulated entity to update its
policies and procedures.
(14) A burden of 1 hour for each regulated entity to update
business associate agreements.
(15) A burden of 52.92 hours for each health plan sponsor to modify
safeguards for its relevant electronic information systems to meet
Security Rule standards.
List of Subjects
45 CFR Part 160
Administrative practice and procedure, Computer technology,
Electronic information system, Electronic transactions, Employer
benefit plan, Group health plan, Health, Health care, Health
facilities, Health insurance, Health professions, Health records,
Hospitals, Investigations, Medicaid, Medical Research, Medicare,
Penalties, Preemption, Privacy, Public health, Reporting and
recordkeeping requirements, Security.
45 CFR Part 164
Administrative practice and procedure, Computer technology, Drug
abuse, Electronic information system, Electronic transactions, Employer
benefit plan, Group health plan, Health, Health care, Health
facilities, Health insurance, Health professions, Health records,
Hospitals, Medicaid, Medical research, Medicare, Privacy, Public
health, Reporting and recordkeeping requirements, Security.
Proposed Rule
For the reasons stated in the preamble, the Department of Health
and Human Services proposes to amend 45 CFR subtitle A, subchapter C,
parts 160 and 164 as set forth below:
PART 160--GENERAL ADMINISTRATIVE REQUIREMENTS
0
1. The authority citation for part 160 continues to read as follows:
Authority: 42 U.S.C. 1302(a); 42 U.S.C. 1320d-1320d-9; sec.
264, Pub. L. 104-191, 110 Stat. 2033-2034 (42 U.S.C. 1320d-2
(note)); 5 U.S.C. 552; secs. 13400-13424, Pub. L. 111-5, 123 Stat.
258-279; and sec. 1104 of Pub. L. 111-148, 124 Stat. 146-154.
0
2. Amend Sec. 160.103 by revising the definition of ``Electronic
media'' to read as follows:
Sec. 160.103 Definitions.
* * * * *
Electronic media means:
(1) Electronic storage material on which data may be recorded,
maintained, or processed. This includes, but is not limited to, hard
drives,
[[Page 1011]]
removable media, magnetic tape, optical disk, and any other form of
digital memory or storage.
(2) Transmission media used to exchange information already in
electronic storage material. Transmission media includes, but is not
limited to, the internet, extranet or intranet, leased lines, dial-up
lines, private and public networks, and the physical movement of
removable/transportable electronic storage material.
* * * * *
PART 164--SECURITY AND PRIVACY
0
1. The authority citation for part 164 continues to read as follows:
Authority: 42 U.S.C. 1302(a); 42 U.S.C. 1320d-1320d-9; sec. 264,
Pub. L. 104-191, 110 Stat. 2033-2034 (42 U.S.C. 1320d-2(note)); and
secs. 13400-13424, Pub. L. 111-5, 123 Stat. 258-279.
0
2. Revise and republish subpart C to read as follows:
Subpart C--Security Standards for the Protection of Electronic
Protected Health Information
Sec.
164.302 Applicability.
164.304 Definitions.
164.306 Security standards: General rules.
164.308 Administrative safeguards.
164.310 Physical safeguards.
164.312 Technical safeguards.
164.314 Organizational requirements.
164.316 Documentation requirements.
164.318 Transition provisions.
164.320 Severability.
Appendix A to Subpart C of Part 164--Security Standards: Matrix
Authority: 42 U.S.C. 1320d-2 and 1320d-4; 42 U.S.C. 17931.
Sec. 164.302 Applicability.
A covered entity or business associate must comply with the
applicable standards, implementation specifications, and requirements
of this subpart with respect to electronic protected health information
of a covered entity.
Sec. 164.304 Definitions.
As used in this subpart, the following terms have the following
meanings:
Access means the ability or the means necessary to read, write,
modify, delete, transmit, or communicate data/information or otherwise
use any component of an information system. (This definition applies to
``access'' as used in this subpart, not as used in subpart D or E of
this part.)
Administrative safeguards are administrative actions and related
policies and procedures to manage the selection, development,
implementation, and maintenance (including updating and modifying) of
security measures to protect electronic protected health information,
and to manage the conduct of the covered entity's or business
associate's workforce in relation to the protection of that
information.
Authentication means the corroboration that a person or technology
asset is the one they are claiming to be.
Availability means the property that data or information is
accessible and useable upon demand by an authorized person or
technology asset.
Confidentiality means the property that data or information is not
made available or disclosed to unauthorized persons, technology assets,
or processes.
Deploy means to configure technology for use and implement such
technology.
Electronic information system means interconnected set of
electronic information resources under the same direct management
control that shares common functionality. An electronic information
system generally includes technology assets, such as hardware,
software, electronic media, information, and data.
Encryption means the use of an algorithmic process to transform
data into a form in which there is a low probability of assigning
meaning without use of a confidential process or key.
Facility means the physical premises and the interior and exterior
of a building(s).
Implement means to put into effect and be in use, operational, and
function as expected throughout the covered entity or business
associate.
Information system means an interconnected set of information
resources under the same direct management control that shares common
functionality. An information system generally includes hardware,
software, information, data, communications, and people.
Integrity means the property that data or information have not been
altered or destroyed in an unauthorized manner.
Malicious software means software or firmware intended to perform
an unauthorized action or activity that will have adverse impact on an
electronic information system and/or the confidentiality, integrity, or
availability of electronic protected health information. Examples
include but are not limited to viruses, worms, Trojan horses, spyware,
and some forms of adware.
Multi-factor authentication means authentication of the user's
identity through verification of at least two of the following three
categories:
(1) Information known by the user, including but not limited to a
password or personal identification number (PIN).
(2) Item possessed by the user, including but not limited to a
token or a smart identification card.
(3) Personal characteristic of the user, including but not limited
to fingerprint, facial recognition, gait, typing cadence, or other
biometric or behavioral characteristics.
Password means confidential authentication information composed of
a string of characters, such as letters, numbers, spaces, and other
symbols.
Physical safeguards are physical measures and related policies and
procedures to protect a covered entity's or business associate's
relevant electronic information systems, and related facilities and
equipment, from natural and environmental hazards and unauthorized
intrusion.
Relevant electronic information system means an electronic
information system that creates, receives, maintains, or transmits
electronic protected health information or that otherwise affects the
confidentiality, integrity, or availability of electronic protected
health information.
Risk means the extent to which the confidentiality, integrity, or
availability of electronic protected health information is threatened
by a potential circumstance or event.
Security or security measures encompass all of the administrative,
physical, and technical safeguards in or applied to an information
system.
Security incident means any of the following:
(1) The attempted or successful unauthorized access, use,
disclosure, modification, or destruction of information in an
information system.
(2) The attempted or successful unauthorized interference with
system operations in an information system.
Technical controls means the technical mechanisms contained in the
hardware, software, or firmware components of an electronic information
system that are primarily implemented and executed by the electronic
information system to protect the information system and data therein.
Technical safeguards means the technology, technical controls, and
related policies and procedures governing the use of the technology
that protects and controls access to electronic protected health
information.
Technology asset means the components of an electronic information
system, including but not
[[Page 1012]]
limited to hardware, software, electronic media, information, and data.
Threat means any circumstance or event with the potential to
adversely affect the confidentiality, integrity, or availability of
electronic protected health information.
User means a person with authorized access.
Vulnerability means a flaw or weakness in an information system,
information system security procedures, design, implementation, or
technical controls that could be intentionally exploited or
accidentally triggered by a threat.
Workstation means an electronic computing device and electronic
media stored in its immediate environment. Workstation includes but is
not limited to the following types of devices: a server, desktop
computer, laptop computer, virtual device, and mobile device such as a
smart phone or tablet.
Sec. 164.306 Security standards: General rules.
(a) General requirements. Each covered entity and business
associate must do the following with respect to all electronic
protected health information it creates, receives, maintains, or
transmits:
(1) Ensure the confidentiality, integrity, and availability of the
electronic protected health information.
(2) Protect against any reasonably anticipated threats or hazards
to the confidentiality, integrity, or availability of the electronic
protected health information.
(3) Protect against any reasonably anticipated uses or disclosures
of the electronic protected health information that are not permitted
or required under subpart E of this part.
(4) Ensure compliance by its workforce with this subpart and all
administrative, physical, and technical safeguards implemented in
accordance with this subpart.
(b) Flexibility of approach. (1) Covered entities and business
associates may use any reasonable and appropriate security measures
that allow the covered entity or business associate to implement the
standards and implementation specifications as specified in this
subpart.
(2) In deciding which security measures to use, a covered entity or
business associate must take into account all of the following factors:
(i) The size, complexity, and capabilities of the covered entity or
business associate.
(ii) The covered entity's or the business associate's technical
infrastructure, hardware, and software security capabilities.
(iii) The costs of security measures.
(iv) The probability and criticality of potential risks to
electronic protected health information.
(v) The effectiveness of the security measure in supporting the
resiliency of the covered entity or business associate.
(c) Standards and implementation specifications. A covered entity
or business associate must comply with the applicable standards,
including their implementation specifications, as provided in this
subpart.
Sec. 164.308 Administrative safeguards.
(a) A covered entity or business associate must, in accordance with
Sec. Sec. 164.306 and 164.316, implement all of the following
administrative safeguards to protect the confidentiality, integrity,
and availability of all electronic protected health information that it
creates, receives, maintains, or transmits:
(1) Standard: Technology asset inventory--(i) General. Conduct and
maintain an accurate and thorough written inventory and a network map
of the covered entity's or business associate's electronic information
systems and all technology assets that may affect the confidentiality,
integrity, or availability of electronic protected health information.
(ii) Implementation specifications--(A) Inventory. Develop a
written inventory of the covered entity's or business associate's
technology assets that contains the identification, version, person
accountable, and location of each technology asset.
(B) Network map. Develop a network map that illustrates the
movement of electronic protected health information throughout the
covered entity's or business associate's electronic information
systems, including but not limited to how electronic protected health
information enters and exits such information systems, and is accessed
from outside of such information systems.
(C) Maintenance. Review and update the written inventory of
technology assets required by paragraph (a)(1)(ii)(A) of this section
and the network map required by paragraph (a)(1)(ii)(B) of this section
in the following circumstances:
(1) On an ongoing basis, but at least once every 12 months.
(2) When there is a change in the covered entity's or business
associate's environment or operations that may affect electronic
protected health information, including but not limited to the adoption
of new technology assets; the upgrading, updating, or patching of
technology assets; newly recognized threats to the confidentiality,
integrity, or availability of electronic protected health information;
a sale, transfer, merger, or consolidation of all or part of the
covered entity or business associate with another person; a security
incident that affects the confidentiality, integrity, and availability
of electronic protected health information; and relevant changes in
Federal, State, Tribal, or territorial law.
(2) Standard: Risk analysis--(i) General. Conduct an accurate and
comprehensive written assessment of the potential risks and
vulnerabilities to the confidentiality, integrity, and availability of
all electronic protected health information created, received,
maintained, or transmitted by the covered entity or business associate.
(ii) Implementation specifications--(A) Assessment. The written
assessment must include, at a minimum, all of the following:
(1) A review of the technology asset inventory required by
paragraph (a)(1)(ii)(A) of this section and the network map required by
paragraph (a)(1)(ii)(B) of this section to identify where electronic
protected health information may be created, received, maintained, or
transmitted within the covered entity's or business associate's
electronic information systems.
(2) Identification of all reasonably anticipated threats to the
confidentiality, integrity, and availability of electronic protected
health information that the covered entity or business associate
creates, receives, maintains, or transmits.
(3) Identification of potential vulnerabilities and predisposing
conditions to the covered entity's or business associate's relevant
electronic information systems.
(4) An assessment and documentation of the security measures the
covered entity or business associate uses to ensure the
confidentiality, integrity, and availability of the electronic
protected health information created, received, maintained, or
transmitted by the covered entity or business associate.
(5) A reasonable determination of the likelihood that each threat
identified in accordance with paragraph (a)(2)(ii)(A)(2) of this
section will exploit the vulnerabilities identified in accordance with
paragraph (a)(2)(ii)(A)(3) of this section.
(6) A reasonable determination of the potential impact of each
threat identified in accordance with paragraph (a)(2)(ii)(A)(2) of this
section successfully exploiting the vulnerabilities identified in
accordance with paragraph (a)(2)(ii)(A)(3) of this section.
[[Page 1013]]
(7) An assessment of risk level for each threat identified in
accordance with paragraph (a)(2)(ii)(A)(2) of this section and
vulnerability identified in accordance with paragraph (a)(2)(ii)(A)(3)
of this section, based on the determinations made in accordance with
paragraphs (a)(2)(ii)(A)(5) and (6) of this section.
(8) An assessment of the risks to electronic protected health
information posed by entering into or continuing a business associate
contract or other written arrangement with any prospective or current
business associate, respectively, based on the written verification
obtained from the prospective or current business associate in
accordance with paragraph (b)(1) of this section.
(B) Maintenance. Review, verify, and update the written assessment
on an ongoing basis, but at least once every 12 months and, in
accordance with paragraph (a)(1)(ii)(C)(2) of this section, in response
to a change in the covered entity's or business associate's environment
or operations that may affect electronic protected health information.
(3) Standard: Evaluation--(i) General. Perform a written technical
and nontechnical evaluation to determine whether a change in the
covered entity's or business associate's environment or operations may
affect the confidentiality, integrity, or availability of electronic
protected health information.
(ii) Implementation specifications--(A) Performance. Perform a
written technical and nontechnical evaluation within a reasonable
period of time before making a change in the covered entity's or
business associate's environment or operations as described in
paragraph (a)(1)(ii)(C)(2) of this section.
(B) Response. Respond to the written technical and nontechnical
evaluation in accordance with the covered entity's or business
associate's risk management plan required by paragraph (a)(5)(ii)(A) of
this section.
(4) Standard: Patch management--(i) General. Implement written
policies and procedures for applying patches and updating the
configuration(s) of the covered entity's or business associate's
relevant electronic information systems.
(ii) Implementation specifications--(A) Policies and procedures.
Establish written policies and procedures for identifying,
prioritizing, acquiring, installing, evaluating, and verifying the
timely installation of patches, updates, and upgrades throughout the
covered entity's or business associate's relevant electronic
information systems.
(B) Maintenance. Review and test written policies and procedures
required by paragraph (a)(4)(ii)(A) of this section at least once every
12 months, and modify such policies and procedures as reasonable and
appropriate.
(C) Application. Patch, update, and upgrade the configurations of
relevant electronic information systems in accordance with the written
policies and procedures required by paragraph (a)(4)(ii)(A) of this
section and based on the results of the covered entity's or business
associate's risk analysis required by paragraph (a)(2) of this section,
the vulnerability scans required by Sec. 164.312(h)(2)(i), the
monitoring of authoritative sources required by Sec.
164.312(h)(2)(ii), and penetration tests required by Sec.
164.312(h)(2)(iii), within a reasonable and appropriate period of time,
as follows, except to the extent that an exception at paragraph
(a)(4)(ii)(D) of this section applies:
(1) Within 15 calendar days of identifying the need to patch,
update, or upgrade the configuration of a relevant electronic
information system to address a critical risk in accordance with this
paragraph (a)(4)(ii)(C), where a patch, update, or upgrade is
available; or, where a patch, update, or upgrade is not available,
within 15 calendar days of a patch, update, or upgrade becoming
available.
(2) Within 30 calendar days of identifying the need to patch,
update, or upgrade the configuration of a relevant electronic
information system to address a high risk in accordance with this
paragraph (a)(4)(ii)(C), where a patch, update, or upgrade is
available; or, where a patch, update, or upgrade is not available,
within 30 calendar days of a patch, update, or upgrade becoming
available.
(3) As determined by and documented in the covered entity's or
business associate's policies and procedures under paragraph
(a)(4)(ii)(A) of this section for all other patches, updates, and
upgrades to the configuration of a relevant electronic information
system.
(D) Exceptions. This paragraph (a)(4)(ii)(D) applies only to the
extent that a covered entity or business associate documents that an
exception in this paragraph (a)(4)(ii)(D) applies and that all other
applicable conditions are met.
(1) A patch, update, or upgrade to the configuration of a relevant
electronic information system is not available to address a risk
identified in the risk analysis under paragraph (a)(2) of this section.
(2) The only available patch, update, or upgrade would adversely
affect the confidentiality, integrity, or availability of electronic
protected health information.
(E) Alternative measures. Where an exception at paragraph
(a)(4)(ii)(D) of this section applies, a covered entity or business
associate must document in real-time the existence of an applicable
exception and implement reasonable and appropriate compensating
controls in accordance with paragraph (a)(4)(ii)(F) of this section.
(F) Compensating controls. To the extent that a covered entity or
business associate determines that an exception at paragraph
(a)(4)(ii)(D) of this section applies, a covered entity or business
associate must implement reasonable and appropriate security measures
to address the identified risk in a timely manner as required by
paragraph (a)(5)(ii)(D) of this section until a patch, update, or
upgrade that does not adversely affect the confidentiality, integrity,
or availability of electronic protected health information becomes
available.
(5) Standard: Risk management--(i) General. Implement security
measures sufficient to reduce risks and vulnerabilities to all
electronic protected health information to a reasonable and appropriate
level.
(ii) Implementation specifications--(A) Planning. Establish and
implement a written risk management plan for reducing risks to all
electronic protected health information, including but not limited to
those risks identified by the risk analysis under paragraph
(a)(2)(ii)(A) of this section, to a reasonable and appropriate level.
(B) Maintenance. Review the written risk management plan required
by paragraph (a)(5)(ii)(A) of this section at least once every 12
months and as reasonable and appropriate in response to changes in the
risk analysis made in accordance with paragraph (a)(2)(ii)(B) of this
section, and modify as reasonable and appropriate.
(C) Priorities. The written risk management plan must prioritize
the risks identified in the risk analysis required by paragraph
(a)(2)(ii)(A) of this section, based on the risk levels determined by
such risk analysis.
(D) Implementation. Implement security measures in a timely manner
to address the risks identified in the covered entity's or business
associate's risk analysis in accordance with the priorities established
under paragraph (a)(5)(ii)(C) of this section.
(6) Standard: Sanction policy--(i) General. Apply appropriate
sanctions against workforce members who fail to comply with the
security policies and
[[Page 1014]]
procedures of the covered entity or business associate.
(ii) Implementation specifications--(A) Policies and procedures.
Establish written policies and procedures for sanctioning workforce
members who fail to comply with the security policies and procedures of
the covered entity or business associate.
(B) Modifications. Review written sanctions policies and procedures
at least once every 12 months, and modify as reasonable and
appropriate.
(C) Application. Apply and document appropriate sanctions against
workforce members who fail to comply with the security policies and
procedures of the covered entity or business associate in accordance
with the written policies and procedures for sanctioning workforce
members required by paragraph (a)(6)(ii)(A) of this section.
(7) Standard: Information system activity review--(i) General.
Implement written policies and procedures for regularly reviewing
records of activity in the covered entity's or business associate's
relevant electronic information systems.
(ii) Implementation specifications--(A) Policies and procedures.
Establish written policies and procedures for retaining and reviewing
records of activity in the covered entity's or business associate's
relevant electronic information systems by persons and technology
assets, including the frequency for reviewing such records.
(B) Scope. Records of activity in the covered entity's or business
associate's relevant electronic information systems by persons and/or
technology assets include but are not limited to audit trails, event
logs, firewall logs, system logs, data backup logs, access reports,
anti-malware logs, and security incident tracking reports.
(C) Record review. Review records of activity in a covered entity's
or business associate's relevant electronic information systems by
persons and technology assets as often as reasonable and appropriate
for the type of report or log and document such review.
(D) Record retention. Retain records of activity in the covered
entity's or business associate's relevant electronic information
systems by persons and technology assets for a period of time that is
reasonable and appropriate for the type of report or log.
(E) Response. Where a suspected or known security incident is
identified during the review required by paragraph (a)(7)(ii)(C) of
this section, respond in accordance with the covered entity's or
business associate's security incident response plan required by
paragraph (a)(12)(ii)(A)(1) of this section.
(F) Maintenance. Review and test the written policies and
procedures required by paragraph (a)(7)(ii)(A) of this section at least
once every 12 months and modify as reasonable and appropriate.
(8) Standard: Assigned security responsibility. In writing,
identify the security official who is responsible for the development
and implementation of the policies and procedures, written or
otherwise, and deployment of technical controls required by this
subpart for the covered entity or business associate.
(9) Standard: Workforce security--(i) General. Implement written
policies and procedures to ensure that all members of its workforce
have appropriate access to electronic protected health information and
relevant electronic information systems, and to prevent those workforce
members who are not authorized to have access from obtaining access to
electronic protected health information and relevant electronic
information systems.
(ii) Implementation specifications--(A) Authorization and/or
supervision. Establish and implement written procedures for the
authorization and/or supervision of workforce members who access
electronic protected health information or relevant electronic
information systems, or who work in facilities where electronic
protected health information or relevant electronic information systems
might be accessed.
(B) Workforce clearance procedure. Establish and implement written
procedures to determine that the access of a workforce member to
electronic protected health information or relevant electronic
information systems is appropriate in accordance with paragraph
(a)(10)(ii)(B) of this section.
(C) Modification and termination procedures. (1) Establish and
implement written procedures, in accordance with paragraph
(a)(9)(ii)(C)(2) of this section, to terminate a workforce member's
access to electronic protected health information and relevant
electronic information systems, and to facilities where electronic
protected health information or relevant electronic information systems
might be accessed.
(2) A workforce member's access must be terminated as soon as
possible but no later than one hour after the employment of, or other
arrangement with, a workforce member ends.
(D) Notification. (1) Establish and implement written procedures,
in accordance with paragraph (a)(9)(ii)(D)(2) of this section, to
notify another covered entity or business associate of a change in or
termination of access where the workforce member is or was authorized
to access such electronic protected health information or relevant
electronic information systems by the covered entity or business
associate making the notification.
(2) Notification must occur as soon as possible but no later than
24 hours after a change in or termination of a workforce member's
authorization to access electronic protected health information or
relevant electronic information systems maintained by such other
covered entity or business associate.
(E) Maintenance. Review and test written policies and procedures
required under paragraph (a)(9)(ii)(A) through (D) of this section at
least once every 12 months, and modify as reasonable and appropriate.
(10) Standard: Information access management--(i) General.
Establish and implement written policies and procedures for authorizing
access to electronic protected health information and relevant
electronic information systems that are consistent with the applicable
requirements of subpart E of this part.
(ii) Implementation specifications--(A) Isolating health care
clearinghouse functions. If a health care clearinghouse is part of a
larger organization, the clearinghouse must establish and implement
written policies and procedures that protect the electronic protected
health information and relevant electronic information systems of the
clearinghouse from unauthorized access by the larger organization.
(B) Access authorization. Establish and implement written policies
and procedures for granting and revising access to electronic protected
health information and relevant electronic information systems as
necessary and appropriate for each prospective user and technology
asset to carry out their assigned function(s).
(C) Authentication management. Establish and implement written
policies and procedures for verifying the identities of users and
technology assets prior to accessing the covered entity's or business
associate's relevant electronic information systems, including written
policies and procedures for implementing multi-factor authentication
technical controls required by Sec. 164.312(f)(2)(ii) through (v).
(D) Access determination and modification. Establish and implement
written policies and procedures that, based upon the covered entity's
or the business associate's access authorization policies, determine,
document, review, and modify the access of each user and technology
asset to specific components
[[Page 1015]]
of the covered entity's or business associate's relevant electronic
information systems.
(E) Network segmentation. Establish and implement written policies
and procedures that ensure that a covered entity's or business
associate's relevant electronic information systems are segmented to
limit access to electronic protected health information to authorized
workstations.
(F) Maintenance. Review and test the written policies and
procedures required by this paragraph (a)(10)(ii) at least once every
12 months, and modify as reasonable and appropriate.
(11) Standard: Security awareness training--(i) General. Implement
security awareness training for all workforce members on protection of
electronic protected health information and information systems as
necessary and appropriate for the members of the workforce to carry out
their assigned function(s).
(ii) Implementation specifications--(A) Training. A covered entity
or business associate must develop and implement security awareness
training for all workforce members that addresses all of the following:
(1) The written policies and procedures with respect to electronic
protected health information required by this subpart as necessary and
appropriate for the workforce members to carry out their assigned
functions.
(2) Guarding against, detecting, and reporting suspected or known
security incidents, including but not limited to, malicious software
and social engineering.
(3) The written policies and procedures for accessing the covered
entity's or business associate's relevant electronic information
systems, including but not limited to: safeguarding passwords; setting
unique passwords of sufficient strength to ensure the confidentiality,
integrity, and availability of electronic protected health information;
and limitations on sharing passwords.
(B) Timing. A covered entity or business associate must provide
security awareness training as follows:
(1) As required by paragraph (a)(11)(ii)(A) of this section, to
each member of its workforce by no later than the compliance date, and
at least once every 12 months thereafter.
(2) As required by paragraph (a)(11)(ii)(A) of this section, to
each new member of its workforce within a reasonable period of time but
no later than 30 days after the person first has access to the covered
entity's or business associate's relevant electronic information
systems.
(3) On a material change to the policies or procedures required by
this subpart, to each member of its workforce whose functions are
affected by such change, within a reasonable period of time but no
later than 30 days after the material change occurs.
(C) Ongoing education. A covered entity or business associate must
provide its workforce members ongoing reminders of their security
responsibilities and notifications of relevant threats, including but
not limited to new and emerging malicious software and social
engineering.
(D) Documentation. A covered entity or business associate must
document that the training required by paragraph (a)(11)(ii)(A) of this
section and ongoing reminders required by paragraph (a)(11)(ii)(C) of
this section have been provided.
(12) Standard: Security incident procedures--(i) General. Implement
written policies and procedures to respond to security incidents.
(ii) Implementation specifications--(A) Planning and testing. (1)
Establish written security incident response plan(s) and procedures
documenting how workforce members are to report suspected or known
security incidents and how the covered entity or business associate
will respond to suspected or known security incidents in accordance
with paragraph (a)(12)(ii)(B) of this section.
(2) Implement written procedures for testing and revising security
incident response plan(s) required by paragraph (a)(12)(ii)(A)(1) of
this section.
(3) Review and test security incident response plan(s) and
procedures required by paragraph (a)(12)(ii)(A)(1) of this section at
least once every 12 months, document the results of such tests, and
modify security incident response plan(s) and procedures as reasonable
and appropriate.
(B) Response. (1) Identify and respond to suspected or known
security incidents.
(2) Mitigate, to the extent practicable, harmful effects of
security incidents that are suspected or known to the covered entity or
business associate.
(3) Identify and remediate, to the extent practicable, the root
cause(s) of security incidents that are suspected or known to the
covered entity or business associate.
(4) Eradicate the security incidents that are suspected or known to
the covered entity or business associate.
(5) For suspected and known security incidents, develop and
maintain documentation of investigations, analyses, mitigation, and
remediation.
(13) Standard: Contingency plan--(i) General. Establish and
implement as needed a written contingency plan, consisting of written
policies and procedures for responding to an emergency or other
occurrence--including but not limited to fire, vandalism, system
failure, natural disaster, or security incident--that adversely affects
relevant electronic information systems.
(ii) Implementation specifications--(A) Criticality analysis.
Perform and document an assessment of the relative criticality of the
covered entity's or business associate's relevant electronic
information systems and technology assets in its relevant electronic
information systems.
(B) Data backups. Establish and implement written procedures to
create and maintain exact retrievable copies of electronic protected
health information, including verification that the electronic
protected health information has been copied accurately.
(C) Information systems backups. Establish and implement written
procedures to create and maintain backups of the covered entity's or
business associate's relevant electronic information systems, including
verification of success of backups.
(D) Disaster recovery plan. (1) Establish (and implement as needed)
written procedures to restore loss of the covered entity's or business
associate's critical relevant electronic information systems and data
within 72 hours of the loss.
(2) Establish (and implement as needed) written procedures to
restore loss of the covered entity's or business associate's other
relevant electronic information systems and data in accordance with the
criticality analysis required by paragraph (a)(13)(ii)(A) of this
section.
(E) Emergency mode operation plan. Establish (and implement as
needed) written procedures to enable continuation of critical business
processes for protection of the security of electronic protected health
information while operating in emergency mode.
(F) Testing and revision procedures. (1) Establish written
procedures for testing and revising contingency plans as required by
this paragraph (a)(13) in accordance with paragraph (a)(13)(ii)(F)(2)
of this section.
(2) Review and test contingency plans required by this paragraph
(a)(13) at least once every 12 months, document the results of such
tests, and modify such contingency plans as reasonable and appropriate
in accordance with the results of those tests.
[[Page 1016]]
(14) Standard: Compliance audit. Perform and document an audit at
least once every 12 months of the covered entity's or business
associate's compliance with each standard and implementation
specification in this subpart.
(b)(1) Standard: Business associate contracts and other
arrangements. (i)(A) A covered entity may permit a business associate
to create, receive, maintain, or transmit electronic protected health
information on the covered entity's behalf only if the covered entity
obtains satisfactory assurances, in accordance with Sec. 164.314(a),
that the business associate will comply with this subpart and verifies
that the business associate has deployed technical safeguards in
accordance with the requirements of Sec. 164.312.
(B) A covered entity is not required to obtain such satisfactory
assurances or verification from a business associate that is a
subcontractor.
(ii) A business associate may permit a business associate that is a
subcontractor to create, receive, maintain, or transmit electronic
protected health information on its behalf only if the business
associate obtains satisfactory assurances, in accordance with Sec.
164.314(a), that the subcontractor will comply with the requirements of
this subpart and verifies that the business associate that is a
subcontractor has deployed technical safeguards in accordance with the
requirements of Sec. 164.312.
(2) Implementation specifications--(i) Written contract or other
arrangement. Document the satisfactory assurances required by paragraph
(b)(1)(i) or (ii) of this section through a written contract or other
arrangement with the business associate that meets the applicable
requirements of Sec. 164.314(a).
(ii) Written verification. Obtain written verification from the
business associate at least once every 12 months that the business
associate has deployed the technical safeguards as required by Sec.
164.312 through both of the following:
(A) A written analysis of the business associate's relevant
electronic information systems by a person with appropriate knowledge
of and experience with generally accepted cybersecurity principles and
methods for ensuring the confidentiality, integrity, and availability
of electronic protected health information to verify compliance with
each standard and implementation specification in Sec. 164.312.
(B) A written certification that the analysis has been performed
and is accurate by a person who has the authority to act on behalf of
the business associate.
(3) Standard: Delegation to business associate. (i) A covered
entity or business associate may permit a business associate to serve
as their designated security official.
(ii) A covered entity or business associate that delegates actions,
activities, or assessments required by this subpart to a business
associate remains liable for compliance with all applicable provisions
of this subpart.
Sec. 164.310 Physical safeguards.
Each covered entity and business associate must, in accordance with
Sec. Sec. 164.306 and 164.316, implement all of the following physical
safeguards to protect the confidentiality, integrity, and availability
of all electronic protected health information that it creates,
receives, maintains, or transmits:
(a) Standard: Facility access controls--(1) General. Establish and
implement written policies and procedures to limit physical access to
all of its relevant electronic information systems and the facility or
facilities in which they are housed, while ensuring that properly
authorized access is allowed.
(2) Implementation specifications--(i) Contingency operations.
Establish (and implement as needed) written procedures that allow
facility access in support of the covered entity's or business
associate's contingency plan required by Sec. 164.308(a)(13).
(ii) Facility security plan. Establish and implement written
policies and procedures to safeguard all facilities and the equipment
therein from unauthorized physical access, tampering, and theft.
(iii) Access management and validation procedures. Establish and
implement written procedures to authorize and manage a person's access
to facilities based on their role or function, including visitor
management.
(iv) Physical maintenance records. Establish and implement written
policies and procedures to document repairs and modifications to the
physical components of a facility that are related to security,
including but not limited to hardware, walls, doors, locks, and
security cameras.
(v) Maintenance. For each facility, review and test the written
policies and procedures required by this paragraph (a)(2) at least once
every 12 months, and modify such policies and procedures as reasonable
and appropriate.
(b) Standard: Workstation use--(1) General. Establish and implement
written policies and procedures that govern the use of workstations
that access electronic protected health information or the covered
entity's or business associate's relevant electronic information
systems.
(2) Implementation specifications--(i) Policies and procedures. The
written policies and procedures must specify all of the following with
respect to a workstation that accesses electronic protected health
information or the covered entity's or business associate's relevant
electronic information systems:
(A) The functions for which a workstation may be used.
(B) The manner in which a workstation may be used to perform those
functions.
(C) The physical attributes of the surroundings of a specific
workstation or class of workstation that can access electronic
protected health information, including the removal of such
workstations from a facility and the movement of such workstations
within and outside of a facility.
(ii) Maintenance. Review and test written policies and procedures
at least once every 12 months, and modify as reasonable and
appropriate.
(c) Standard: Workstation security. Implement and modify physical
safeguards for all workstations that access electronic protected health
information or relevant electronic information systems, to address the
written policies and procedures for workstation use required by
paragraph (b) of this section and restrict access to authorized users.
(d) Standard: Technology asset controls--(1) General. Establish and
implement written policies and procedures that govern the receipt and
removal of technology assets that maintain electronic protected health
information into and out of a facility, and the movement of these
assets within the facility.
(2) Implementation specifications--(i) Disposal. Establish and
implement written policies and procedures for disposal of electronic
protected health information and the technology assets on which it is
maintained based on current standards for disposing of such technology
assets.
(ii) Media sanitization. Establish and implement written procedures
for removal of electronic protected health information from electronic
media such that the electronic protected health information cannot be
recovered, based on current standards for sanitizing electronic media
before the media are made available for re-use.
(iii) Maintenance. Review and test the written policies and
procedures required by paragraphs (d)(2)(i) and (ii)
[[Page 1017]]
of this section at least once every 12 months or in response to
environmental or operational changes, whichever is more frequent, and
modify as reasonable and appropriate.
Sec. 164.312 Technical safeguards.
Each covered entity or business associate must, in accordance with
Sec. Sec. 164.306 and 164.316, implement all of the following
technical safeguards, including technical controls, to protect the
confidentiality, integrity, and availability of all electronic
protected health information that it creates, receives, maintains, or
transmits:
(a) Standard: Access control--(1) General. Deploy technical
controls in relevant electronic information systems to allow access
only to users and technology assets that have been granted access
rights.
(2) Implementation specifications--(i) Unique identification.
Assign a unique name, number, and/or other identifier for tracking each
user and technology asset in the covered entity or business associate's
relevant electronic information systems.
(ii) Administrative and increased access privileges. Separate user
identities from identities used for administrative and other increased
access privileges.
(iii) Emergency access procedure. Establish (and implement as
needed) written and technical procedures for obtaining necessary
electronic protected health information during an emergency.
(iv) Automatic logoff. Deploy technical controls that terminate an
electronic session after a predetermined time of inactivity that is
reasonable and appropriate.
(v) Log-in attempts. Deploy technical controls that disable or
suspend the access of a user or technology asset to relevant electronic
information systems after a reasonable and appropriate predetermined
number of unsuccessful authentication attempts.
(vi) Network segmentation. Deploy technical controls to ensure that
the covered entity's or business associate's relevant electronic
information systems are segmented in a reasonable and appropriate
manner.
(vii) Data controls. Deploy technical controls to allow access to
electronic protected health information only to those users and
technology assets that have been granted access rights to the covered
entity's or business associate's relevant electronic information
systems as specified in Sec. 164.308(a)(10).
(viii) Maintenance. Review and test the effectiveness of the
procedures and technical controls required by this paragraph (a)(2) at
least once every 12 months or in response to environmental or
operational changes, whichever is more frequent, and modify as
reasonable and appropriate.
(b) Standard: Encryption and decryption--(1) General. Deploy
technical controls to encrypt and decrypt electronic protected health
information using encryption that meets prevailing cryptographic
standards.
(2) Implementation specification. Encrypt all electronic protected
health information at rest and in transit, except to the extent that an
exception at paragraph (b)(3) of this section applies.
(3) Exceptions. This paragraph (b)(3) applies only to the
electronic protected health information directly affected by one or
more of the following exceptions and only to the extent that the
covered entity or business associate documents that an exception
applies and that all other applicable conditions are met.
(i) The technology asset in use does not support encryption of the
electronic protected health information consistent with prevailing
cryptographic standards, and the covered entity or business associate
establishes and implements a written plan to migrate electronic
protected health information to a technology asset that supports
encryption consistent with prevailing cryptographic standards within a
reasonable and appropriate period of time.
(ii) An individual requests pursuant to Sec. 164.524 to receive
their electronic protected health information in an unencrypted manner
and has been informed of the risks associated with the transmission,
receipt, and storage of unencrypted electronic protected health
information. This exception does not apply where such individual will
receive their electronic protected health information pursuant to Sec.
164.524 and the technology used by the individual to receive the
electronic protected health information is controlled by the covered
entity or its business associate.
(iii) During an emergency or other occurrence that adversely
affects the covered entity's or business associate's relevant
electronic information systems in which encryption is infeasible, and
the covered entity or business associate implements reasonable and
appropriate compensating controls in accordance with and determined by
the covered entity's or business associate's contingency plan under
Sec. 164.308(a)(13).
(iv) The technology asset in use is a device under section 201(h)
of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been
authorized for marketing by the Food and Drug Administration, as
follows:
(A) Pursuant to a submission received before March 29, 2023,
provided that the covered entity or business associate deploys in a
timely manner any updates or patches required or recommended by the
manufacturer of the device.
(B) Pursuant to a submission received on or after March 29, 2023,
where the device is no longer supported by its manufacturer, provided
that the covered entity or business associate has deployed any updates
or patches required or recommended by the manufacturer of the device.
(C) Pursuant to a submission received on or after March 29, 2023,
where the device is supported by its manufacturer.
(4) Alternative measures--(i) Alternative measures. Where an
exception at paragraph (b)(3) of this section applies, a covered entity
or business associate must document in real-time the existence of an
applicable exception and implement reasonable and appropriate
compensating controls in accordance with paragraph (b)(4)(ii) of this
section.
(ii) Compensating controls. (A) To the extent that a covered entity
or business associate determines that an exception at paragraph
(b)(3)(i), (ii), or (iii) or (b)(3)(iv)(A) or (B) of this section
applies, the covered entity or business associate must secure such
electronic protected health information by implementing reasonable and
appropriate compensating controls reviewed and approved by the covered
entity's or business associate's designated Security Official.
(B) To the extent that a covered entity or business associate
determines that an exception at paragraph (b)(3)(iv)(C) of this section
applies, the covered entity or business associate shall be presumed to
have implemented reasonable and appropriate compensating controls where
the covered entity or business associate has deployed the security
measures prescribed and as instructed by the authorized label for the
device, including any updates or patches recommended or required by the
manufacturer of the device.
(C) To the extent that a covered entity or business associate is
implementing compensating controls under this paragraph (b)(4)(ii), the
implementation and effectiveness of compensating controls must be
reviewed, documented, and signed by the designated Security Official at
least once every 12 months or in response to environmental or
operational changes, whichever is more frequent, to continue securing
electronic protected health information and relevant electronic
information systems.
[[Page 1018]]
(5) Maintenance. Review and test the effectiveness of the technical
controls required by this paragraph (b) at least once every 12 months
or in response to environmental or operational changes, whichever is
more frequent, and modify as reasonable and appropriate.
(c) Standard: Configuration management--(1) General. Establish and
deploy technical controls for securing the covered entity's or business
associate's relevant electronic information systems and technology
assets in its relevant electronic information systems, including
workstations, in a consistent manner, and maintain such electronic
information systems and technology assets according to the covered
entity's or business associate's established secure baselines.
(2) Implementation specifications--(i) Anti-malware protection.
Deploy technology assets and/or technical controls that protect all of
the covered entity's or business associate's technology assets in its
relevant electronic information systems against malicious software,
including but not limited to viruses and ransomware.
(ii) Software removal. Remove extraneous software from the covered
entity's or business associate's relevant electronic information
systems.
(iii) Configuration. Configure and secure operating system(s) and
software consistent with the covered entity's or business associate's
risk analysis under Sec. 164.308(a)(2).
(iv) Network ports. Disable network ports in accordance with the
covered entity's or business associate's risk analysis under Sec.
164.308(a)(2).
(v) Maintenance. Review and test the effectiveness of the technical
controls required by this paragraph (c) at least once every 12 months
or in response to environmental or operational changes, whichever is
more frequent, and modify as reasonable and appropriate.
(d) Standard: Audit trail and system log controls--(1) General.
Deploy technology assets and/or technical controls that record and
identify activity in the covered entity's or business associate's
relevant electronic information systems.
(2) Implementation specifications--(i) Monitor and identify. The
covered entity or business associate must deploy technology assets and/
or technical controls that monitor in real-time all activity in its
relevant electronic information systems, identify indications of
unauthorized persons or unauthorized activity as determined by the
covered entity's or business associate's risk analysis under Sec.
164.308(a)(2), and alert workforce members of such indications in
accordance with the policies and procedures required by Sec.
164.308(a)(7).
(ii) Record. The covered entity or business associate must deploy
technology assets and/or technical controls that record in real-time
all activity in its relevant electronic information systems.
(iii) Retain. The covered entity or business associate must deploy
technology assets and/or technical controls to retain records of all
activity in its relevant electronic information systems as determined
by the covered entity's or business associate's policies and procedures
for information system activity review at Sec. 164.308(a)(7)(ii)(A).
(iv) Scope. Activity includes creating, accessing, receiving,
transmitting, modifying, copying, or deleting any of the following:
(A) Electronic protected health information.
(B) Relevant electronic information systems and the information
therein.
(v) Maintenance. Review and test the effectiveness of the
technology assets and/or technical controls required by this paragraph
(d) at least once every 12 months or in response to environmental or
operational changes, whichever is more frequent, and modify as
reasonable and appropriate.
(e) Standard: Integrity. Deploy technical controls to protect
electronic protected health information from improper alteration or
destruction, both at rest and in transit; and review and test the
effectiveness of such technical controls at least once every 12 months
or in response to environmental or operational changes, whichever is
more frequent, and modify as reasonable and appropriate.
(f) Standard: Authentication--(1) General. Deploy technical
controls to verify that a person or technology asset seeking access to
electronic protected health information and/or the covered entity's or
business associate's relevant electronic information systems is the one
claimed.
(2) Implementation specifications--(i) Information access
management policies. Deploy technical controls in accordance with the
covered entity's or business associate's information access management
policies and procedures under Sec. 164.308(a)(10), including technical
controls that require users to adopt unique passwords that are
consistent with the current recommendations of authoritative sources.
(ii) Multi-factor authentication. (A) Deploy multi-factor
authentication to all technology assets in the covered entity's or
business associate's relevant electronic information systems to verify
that a person seeking access to the relevant electronic information
system(s) is the user that the person claims to be.
(B) Deploy multi-factor authentication for any action that would
change a user's privileges to the covered entity's or business
associate's relevant electronic information systems in a manner that
would alter the user's ability to affect the confidentiality,
integrity, or availability of electronic protected health information.
(iii) Exceptions. Deployment of multi-factor authentication is not
required in any of the following circumstances.
(A) The technology asset in use does not support multi-factor
authentication, and the covered entity or business associate
establishes and implements a written plan to migrate electronic
protected health information to a technology asset that supports multi-
factor authentication within a reasonable and appropriate period of
time.
(B) During an emergency or other occurrence that adversely affects
the covered entity's or business associate's relevant electronic
information systems or the confidentiality, integrity, or availability
of electronic protected health information in which multi-factor
authentication is infeasible and the covered entity or business
associate implements reasonable and appropriate compensating controls
in accordance with its emergency access procedures under paragraph
(a)(2)(iii) of this section and the covered entity's or business
associate's contingency plan under Sec. 164.308(a)(13).
(C) The technology asset in use is a device under section 201(h) of
the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been
authorized for marketing by the Food and Drug Administration, as
follows:
(1) Pursuant to a submission received before March 29, 2023,
provided that the covered entity or business associate has deployed any
updates or patches required or recommended by the manufacturer of the
device.
(2) Pursuant to a submission received on or after March 29, 2023,
where the device is no longer supported by its manufacturer, provided
that the covered entity or business associate has deployed any updates
or patches required or recommended by the manufacturer of the device.
(3) Pursuant to a submission received on or after March 29, 2023,
where the device is supported by its manufacturer.
(iv) Alternative measures--(A) Alternative measures. Where an
exception at paragraph (f)(2)(iii) of this
[[Page 1019]]
section applies, a covered entity or business associate must document
in real-time the existence of an applicable exception and implement
reasonable and appropriate compensating controls as required by
paragraph (f)(2)(iv)(B) of this section.
(B) Compensating controls. (1) To the extent that a covered entity
or business associate determines that an exception at paragraph
(f)(2)(iii)(A) or (B) or (f)(2)(iii)(C)(1) or (2) of this section
applies, the covered entity or business associate must secure its
relevant electronic information systems by implementing reasonable and
appropriate compensating controls reviewed, approved, and signed by the
covered entity's or business associate's designated Security Official.
(2) To the extent that a covered entity or business associate
determines that an exception at paragraph (f)(2)(iii)(C)(3) of this
section applies, the covered entity or business associate shall be
presumed to have implemented reasonable and appropriate compensating
controls where the covered entity or business associate has deployed
the security measures prescribed and as instructed by the authorized
label for the device, including any updates or patches recommended or
required by the manufacturer of the device.
(3) To the extent that a covered entity or business associate is
implementing compensating controls under this paragraph (f)(2)(iv)(B),
the effectiveness of compensating controls must be reviewed and
documented by the designated Security Official at least once every 12
months or in response to environmental or operational changes,
whichever is more frequent, to continue securing electronic protected
health information and its relevant electronic information systems.
(v) Maintenance. Review and test the effectiveness of the technical
controls required by this paragraph (f) at least once every 12 months
or in response to environmental or operational changes, whichever is
more frequent, and modify as reasonable and appropriate.
(g) Standard: Transmission security. Deploy technical controls to
guard against unauthorized access to electronic protected health
information that is being transmitted over an electronic communications
network; and review and test the effectiveness of such technical
controls at least once every 12 months or in response to environmental
or operational changes, whichever is more frequent, and modify as
reasonable and appropriate.
(h) Standard: Vulnerability management--(1) General. Deploy
technical controls in accordance with the covered entity's or business
associate's patch management policies and procedures required by Sec.
164.308(a)(4)(ii)(A) to identify and address technical vulnerabilities
in the covered entity's or business associate's relevant electronic
information systems.
(2) Implementation specifications--(i) Vulnerability scanning. (A)
Conduct automated vulnerability scans to identify technical
vulnerabilities in the covered entity's or business associate's
relevant electronic information systems in accordance with the covered
entity's or business associate's risk analysis required by Sec.
164.308(a)(2) or at least once every six months, whichever is more
frequent.
(B) Review and test the effectiveness of the technology asset(s)
that conducts the automated vulnerability scans required by paragraph
(h)(2)(i)(A) of this section at least once every 12 months or in
response to environmental or operational changes, whichever is more
frequent, and modify as reasonable and appropriate.
(ii) Monitoring. Monitor authoritative sources for known
vulnerabilities on an ongoing basis and remediate such vulnerabilities
in accordance with the covered entity's or business associate's patch
management program under Sec. 164.308(a)(4).
(iii) Penetration testing. Perform penetration testing of the
covered entity's or business associate's relevant electronic
information systems by a qualified person.
(A) A qualified person is a person with appropriate knowledge of
and experience with generally accepted cybersecurity principles and
methods for ensuring the confidentiality, integrity, and availability
of electronic protected health information.
(B) Penetration testing must be performed at least once every 12
months or in accordance with the covered entity's or business
associate's risk analysis required by Sec. 164.308(a)(2), whichever is
more frequent.
(iv) Patch and update installation. Deploy technical controls in
accordance with the covered entity's or business associate's patch
management program under Sec. 164.308(a)(4) to ensure timely
installation of software patches and critical updates as reasonable and
appropriate.
(i) Standard: Data backup and recovery--(1) General. Deploy
technical controls to create and maintain exact retrievable copies of
electronic protected health information.
(2) Implementation specifications--(i) Data backup. Create backups
of electronic protected health information in accordance with the
policies and procedures required by Sec. 164.308(a)(13)(ii)(B) and
with such frequency to ensure retrievable copies of electronic
protected health information are no more than 48 hours older than the
electronic protected health information maintained in the covered
entity or business associate's relevant electronic information systems.
(ii) Monitor and identify. Deploy technical controls that, in real-
time, monitor, and alert workforce members about, any failures and
error conditions of the backups required by paragraph (i)(2)(i) of this
section.
(iii) Record. Deploy technical controls that record the success,
failure, and any error conditions of backups required by paragraph
(i)(2)(i) of this section.
(iv) Testing. Restore a representative sample of electronic
protected health information backed up as required by paragraph
(i)(2)(i) of this section, and document the results of such test
restorations at least monthly.
(j) Standard: Information systems backup and recovery. Deploy
technical controls to create and maintain backups of relevant
electronic information systems; and review and test the effectiveness
of such technical controls at least once every six months or in
response to environmental or operational changes, whichever is more
frequent, and modify as reasonable and appropriate.
Sec. 164.314 Organizational requirements.
(a)(1) Standard: Business associate contracts or other
arrangements. The contract or other arrangement required by Sec.
164.308(b)(2) must meet the requirements of paragraph (a)(2)(i), (ii),
or (iii) of this section, as applicable.
(2) Implementation specifications--(i) Business associate
contracts. The contract must provide that the business associate will
do all of the following:
(A) Comply with the applicable requirements of this subpart.
(B) In accordance with Sec. 164.308(b)(1)(ii), ensure that any
subcontractors that create, receive, maintain, or transmit electronic
protected health information on behalf of the business associate agree
to comply with the applicable requirements of this subpart by entering
into a contract or other arrangement that complies with this section.
(C) Report to the covered entity any security incident of which it
becomes aware, including breaches of unsecured electronic protected
health information as required by Sec. 164.410.
(D) Report to the covered entity activation of its contingency plan
under Sec. 164.308(a)(13) without unreasonable
[[Page 1020]]
delay, and in no case later than 24 hours after activation of the
contingency plan.
(ii) Other arrangements. The covered entity is in compliance with
paragraph (a)(1) of this section if it has another arrangement in place
that meets the requirements of Sec. 164.504(e)(3).
(iii) Business associate contracts with subcontractors. The
requirements of paragraphs (a)(2)(i) and (ii) of this section apply to
the contract or other arrangement between a business associate and a
subcontractor required by Sec. 164.308(b)(1)(ii) in the same manner as
such requirements apply to contracts or other arrangements between a
covered entity and business associate.
(b)(1) Standard: Requirements for group health plans. Except when
the only electronic protected health information disclosed to a plan
sponsor is disclosed pursuant to Sec. 164.504(f)(1)(ii) or (iii), or
as authorized under Sec. 164.508, a group health plan must ensure that
its plan documents provide that the plan sponsor will reasonably and
appropriately safeguard electronic protected health information
created, received, maintained, or transmitted to or by the plan sponsor
on behalf of the group health plan.
(2) Implementation specifications. The plan documents of the group
health plan must be amended to incorporate provisions to require the
plan sponsor to do all of the following:
(i) Safeguard implementation. Implement the administrative,
physical, and technical safeguards that covered entities and business
associates are required to implement under Sec. Sec. 164.308(a),
164.310, and 164.312.
(ii) Separation. Ensure that the adequate separation required by
Sec. 164.504(f)(2)(iii) is supported by the administrative, physical,
and technical safeguards implemented in accordance with paragraph
(b)(2)(i) of this section.
(iii) Agents. Ensure that any agent to whom it provides this
information agrees to implement the administrative, physical, and
technical safeguards in accordance with paragraph (b)(2)(i) of this
section.
(iv) Security incident awareness. Report to the group health plan
any security incident of which it becomes aware.
(v) Contingency plan activation. Report to the group health plan
activation of its contingency plan, adopted in accordance with Sec.
164.308(a)(13) as required by paragraph (b)(2)(i) of this section,
without unreasonable delay and in no case later than 24 hours after
activation of the contingency plan.
Sec. 164.316 Documentation requirements.
(a) Standard: Documentation. A covered entity or business associate
must do all of the following in written form, which may be electronic,
taking into consideration the factors in Sec. 164.306(b):
(1) Document the policies and procedures required to comply with
this subpart and how the covered entity or business associate
considered the factors at Sec. 164.306(b) in the development of such
policies and procedures.
(2) Document each action, activity, or assessment required by this
subpart.
(b) Implementation specifications--(1) Time limit. Retain the
documentation required by paragraph (a) of this section for 6 years
from the date of its creation or the date when it last was in effect,
whichever is later.
(2) Availability. Make documentation available to those persons
responsible for implementing the procedures to which the documentation
pertains.
(3) Updates. Review and update documentation at least once every 12
months and within a reasonable and appropriate period of time after a
security measure is modified.
Sec. 164.318 Transition provisions.
(a) Standard: Effect of prior contracts or other arrangements with
business associates. Notwithstanding any other provisions of this
subpart, a covered entity, or business associate with respect to a
subcontractor, may allow a business associate to create, receive,
maintain, or transmit electronic protected health information pursuant
to a written contract or other arrangement with such business associate
that does not comply with Sec. Sec. 164.308(b) and 164.314(a), only in
accordance with paragraph (b) of this section.
(b) Implementation specification: Deemed compliance--(1)
Qualification. Notwithstanding other sections of this subpart, a
covered entity, or business associate with respect to a subcontractor,
is deemed to be in compliance with the documentation and contract
requirements of Sec. Sec. 164.308(b) and 164.314(a), with respect to a
particular business associate relationship for the time period set
forth in paragraph (b)(2) of this section, if both of the following
apply:
(i) Prior to [DATE OF PUBLICATION OF THE FINAL RULE IN THE Federal
Register], such covered entity, or business associate with respect to a
subcontractor, has entered into and is operating pursuant to a written
contract or other written arrangement with the business associate that
complies with the applicable provisions of Sec. Sec. 164.308(b) and
164.314(a) that were in effect on such date.
(ii) The contract or other arrangement is not renewed or modified
from [DATE 60 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE
Federal Register], until [DATE 240 DAYS AFTER DATE OF PUBLICATION OF
THE FINAL RULE IN THE Federal Register].
(2) Limited deemed compliance period. A prior contract or other
arrangement that meets the qualification requirements at paragraph
(b)(1) of this section shall be deemed compliant until the earlier of
the following dates:
(i) The date such contract or other arrangement is renewed on or
after [DATE 240 DAYS AFTER DATE OF PUBLICATION OF THE FINAL RULE IN THE
Federal Register].
(ii) [DATE 1 YEAR AND 60 DAYS AFTER DATE OF PUBLICATION OF THE
FINAL RULE IN THE Federal Register].
(c) Covered entity and business associate responsibilities. Nothing
in this section shall alter the requirements of a covered entity or
business associate to comply with applicable provisions of this part
other than Sec. Sec. 164.308(b) and 164.314(a).
Sec. 164.320 Severability.
If any provision of this subpart is held to be invalid or
unenforceable by its terms, or as applied to any person or
circumstance, or stayed pending further agency action, it shall be
construed so as to give it maximum effect permitted by law, unless such
holding shall be one of utter invalidity or unenforceability, in which
event such provision shall be severable from this subpart and shall not
affect the remainder thereof or the application of such provision to
other persons not similarly situated or to other dissimilar
circumstances.
[[Page 1021]]
Appendix A to Subpart C of Part 164--Security Standards: Matrix
------------------------------------------------------------------------
Implementation
Standards Sections specifications
------------------------------------------------------------------------
Administrative Safeguards
------------------------------------------------------------------------
Technology asset inventory.. 164.308(a)(1) Inventory.
.................... Network map.
.................... Maintenance.
Risk analysis............... 164.308(a)(2) Assessment
.................... Maintenance.
Evaluation.................. 164.308(a)(3) Performance
.................... Response.
Patch Management............ 164.308(a)(4) Policies and
procedures.
.................... Maintenance.
.................... Application.
.................... Exceptions.
.................... Alternative
measures.
.................... Compensating
controls.
Risk management............. 164.308(a)(5) Planning.
.................... Maintenance.
.................... Priorities.
.................... Implementation.
Sanction policy............. 164.308(a)(6) Policies and
procedures.
.................... Modifications.
.................... Application.
Information system activity 164.308(a)(7) Policies and
review. procedures.
.................... Scope.
.................... Record review.
.................... Record retention.
.................... Response.
.................... Maintenance.
Assigned security 164.308(a)(8) ....................
responsibility.
Workforce security.......... 164.308(a)(9) Authorization and/or
supervision.
.................... Workforce clearance
procedure.
.................... Modification and
termination
procedures.
.................... Notification.
.................... Maintenance.
Information access 164.308(a)(10) Isolating health
management. care clearinghouse
functions.
.................... Access
authorization.
.................... Authentication
management.
.................... Access determination
and modification.
.................... Network
segmentation.
.................... Maintenance.
Security awareness training. 164.308(a)(11) Training.
.................... Timing.
.................... Ongoing education.
.................... Documentation.
Security incident procedures 163.308(a)(12) Planning and
testing.
.................... Response.
Contingency plan............ 163.308(a)(13) Criticality
analysis.
.................... Data backups.
.................... Information systems
backups.
.................... Disaster recovery
plan.
.................... Emergency mode
operation plan.
.................... Testing and revision
procedures.
Compliance audit............ 164.308(a)(14) ....................
Business associate contracts 164.308(b)(1) Written contract or
and other arrangements. other arrangement.
.................... Written
verification.
Delegation to business 164.308(b)(3) ....................
associate.
------------------------------------------------------------------------
Physical Safeguards
------------------------------------------------------------------------
Facility access controls.... 164.310(a) Contingency
operations.
.................... Facility security
plan.
.................... Access management
and validation
procedures.
.................... Physical maintenance
records.
.................... Maintenance.
Workstation use............. 164.310(b) Policies and
procedures.
.................... Maintenance.
Workstation security........ 164.310(c) ....................
Technology asset controls... 164.310(d) Disposal.
.................... Media sanitization.
.................... Maintenance.
------------------------------------------------------------------------
[[Page 1022]]
Technical Safeguards
------------------------------------------------------------------------
Access control.............. 164.312(a) Unique
identification.
.................... Administrative and
increased access
privileges.
.................... Emergency access
procedure.
.................... Automatic logoff.
.................... Log-in attempts.
.................... Network
segmentation.
.................... Data controls.
.................... Maintenance.
Encryption and decryption... 164.312(b) Implementation
specification.
.................... Exceptions.
.................... Alternative
measures.
.................... Compensating
controls.
.................... Maintenance.
Configuration management.... 164.312(c) Anti-malware
protection.
.................... Software removal.
.................... Configuration.
.................... Network ports.
.................... Maintenance.
Audit trail and system log 164.312(d) Monitor and
controls. identify.
.................... Record.
.................... Retain.
.................... Scope.
.................... Maintenance.
Integrity................... 164.312(e) ....................
Authentication.............. 164.312(f) Information access
management
policies.
.................... Multi-factor
authentication.
.................... Exceptions.
.................... Alternative
measures.
.................... Compensating
controls.
.................... Maintenance.
Transmission security....... 164.312(g) ....................
Vulnerability management.... 164.312(h) Vulnerability
scanning.
.................... Monitoring.
.................... Penetration testing.
.................... Patch and update
installation.
Data backup and recovery.... 164.312(i) Data backup
.................... Monitor and
identify.
.................... Record.
.................... Testing.
Information systems backup 164.312(j)
and recovery.
------------------------------------------------------------------------
Dated: December 20, 2024.
Xavier Becerra,
Secretary, Department of Health and Human Services.
[FR Doc. 2024-30983 Filed 12-27-24; 4:15 pm]
BILLING CODE 4153-01-P