HIPAA Administrative Safeguards: Key Changes and New Requirements

A lot has changed in the world of healthcare since HIPAA was last updated in 2013. The Department of Health and Human Services (the Department) published a notice of proposed rulemaking (NPRM) on January 6, 2025, to modify the HIPAA Security Rule. The Office of Management and Budget (OMB) currently lists a Final Action date of July 2027.

This would provide regulated entities 240 days to comply with the updated requirements. The proposed rule addresses significant changes in technology, breach trends and cyberattacks, enforcement experience, and best practices for protecting electronic Patient Health Information (ePHI). 

The purpose of this blog is to:

1. Describe the structural relationship of standards and implementation specifications
2. Review proposed changes to the General Rules of the HIPAA Security Rule
3. Describe the proposed administrative safeguards within the HIPAA Security Rule
4. Provide a crosswalk to streamline a HIPAA Security Rule 2013-to-2027 gap analysis

Key Takeaways

• HHS published the proposed Security Rule update in an NPRM on January 6, 2025. OMB currently lists a final action date of July 2027, with 240 days to comply if the rule is finalized as proposed.
• The proposal removes the distinction between “addressable” and “required” implementation specifications, so every specification becomes a requirement.
• In the crosswalk examples below, the 2013 rule only partially satisfies most proposed updates, and some requirements, such as the network map, are entirely new.
• Many standards add written policies and procedures and a review at least every 12 months.
• Starting a gap analysis now lets you close documentation gaps before a final rule publishes.

The table above highlights only a fraction of the proposed updates. To view the complete mapping of all Administrative, Technical, and Physical safeguards, download our full HIPAA Security Rule Crosswalk 2013 to 2027 Spreadsheet. 

HIPAA Security Rule Structural Relationship

The current HIPAA Security Rule consists of a tiered system of requirements:

• Standards - a set of legal requirements regulated entities must meet.
• Implementation Specifications - provide detailed guidance for compliance with a specific standard.

Regulated entities may use any security measures when implementing the standards and implementation specifications. The Security Rule standards generally align with other cybersecurity frameworks. Implementation specifications reflect healthcare industry sensitivities and direct regulated entities how to meet the standards.

Structural relationship mapping defines the hierarchical relationship of concepts from a single source. The Security Rule standard and implementation specification structure is a parent-child relationship. The implementation specifications are part of the standard concept. The Security Rule specifies required child concepts that achieve the parent concept.

Security standards: General Rules § 164.306

The Department proposes collapsing 45 CFR 164.306(c) and (d) into paragraph (c). This change removes the distinction between “addressable” and “required” implementation specifications.

The concept of "addressable implementation specifications" provided regulated entities flexibility. A covered entity should have done one of the following for addressable specifications:

• implement the addressable implementation specifications; 
• implement one or more alternative security measures to accomplish the same purpose; 
• not implement either an addressable implementation specification or an alternative.

Regulated entities decided whether addressable implementation specifications were reasonable and appropriate to apply. OCR’s enforcement suggested that regulated entities treated “addressable” requirements as optional. This led regulated entities to not adopt implementation specifications.

The proposed general rules removes the distinction between ‘addressable” and “required” implementation specifications. The Department believes that eliminating the distinction makes it clear that standards and implementation specifications are requirements. By collapsing § 164.306(c) and (d) into § 164.306(c), the proposed rule states:

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.

Technology asset inventory §164.308(a)(1)

A new standard called technology asset inventory would replace the security management process standard. All four implementation specifications within the security management process standard would become new standards elsewhere within the administrative safeguards:

• Risk analysis becomes a standard at §164.308(a)(2)(i)
• Risk management becomes a standard at §164.308(a)(5)(i)
• Sanction policy becomes a standard at §164.308(a)(6)(i)
• Information system activity review becomes a standard at §164.308(a)(7)(i)

The Technology asset inventory standard requires regulated entities to identify all technology assets that may affect the confidentiality, integrity, or availability of ePHI. This includes information systems that create, receive, maintain, or transmit ePHI. Assets that do not handle ePHI may allow intruders to enter the information systems. This could lead to risks to the confidentiality, integrity, or availability of ePHI. An inventory and network map help identify the risks and vulnerabilities to ePHI.

When multiple entities have control of an asset, each should include it in their inventory and on their network maps. For example, providers have direct management control over ePHI in cloud-based EHRs. Accordingly, both should include the EHR within their inventories and network maps. When third parties control assets, such as servers under the control of cloud provider, the assets would not be part of the provider's system. Assets controlled by third parties would not have to be included in a regulated entity's inventory. However, the cloud provider should be included in the provider's network map.

The technology asset inventory standard would be accompanied by three implementation specifications. Regulated entities that satisfy the implementation specifications achieve the technology asset inventory standard.

Inventory §164.308(a)(1)(ii)(A)

A new inventory implementation specification would establish a written inventory of technology assets. This would include hardware, software, electronic media, information, and data. Technology assets include those that create, receive, maintain, or transmit ePHI and those that may affect its confidentiality, integrity, or availability. The inventory should also include the identification, version, person accountable for, and location of each of the assets or information system components.

Network Map §164.308(a)(1)(ii)(B)

A new network map implementation specification would illustrate the movement of ePHI. This includes how ePHI enters and exits the systems, and access of ePHI from outside the system.

Maintenance §164.308(a)(1)(ii)(C)

A new maintenance implementation specification would review and update the inventory and network map. Reviews should occur at least every 12 months and when there is a change in environment or operations may affect ePHI. Such a change in the regulated entity's environment or operations might include:

• 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
• relevant changes in Federal, State, Tribal, or territorial law.

Risk analysis §164.308(a)(2)(i)

The Department would elevate the risk analysis implementation specification to a standard. The standard would require a written assessment of the potential risks to ePHI. Basic questions to consider when conducting a risk analysis include:

• 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?
• What are the risks posed by legacy devices, including any risks that would be posed by replacing legacy devices with new ones?

The Department proposes two implementation specifications for the risk analysis standard. Regulated entities that satisfy the underlying implementation specifications achieve the risk analysis standard.

Assessment §164.308(a)(2)(ii)(A)

The National Committee on Vital and Health Statistics (NCVHS) presented the Department with a step-by-step risk analysis procedure. The implementation specification for a written assessment draws heavily on the NCVHS recommendations. Regulated entities would, at a minimum, perform and document the following:

1. Review the inventory and network map to identify where ePHI may be created, received, maintained, or transmitted. 
2. Identify all reasonably anticipated threats to the confidentiality, integrity, and availability of ePHI. 
3. Identify potential vulnerabilities to the regulated entity's relevant information systems. This includes systems that create, receive, maintain, or transmit ePHI or that otherwise affect the confidentiality, integrity, or availability of ePHI.
4. Create an assessment and documentation of the security measures it uses to ensure that the measures protect ePHI. 
5. Make a reasonable determination of the likelihood that each identified threat would exploit the identified vulnerabilities. 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.
6. Make a reasonable determination of the potential impact of each identified threat should it successfully exploit the identified vulnerabilities. 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.
7. Create an assessment of risk level for each identified threat and vulnerability. 
8. 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.

Maintenance § 164.308(a)(2)(ii)(B)

A new maintenance implementation specification requires reviewing, verifying, and updating the written assessment on an ongoing basis. This should occur 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.

Evaluation § 164.308(a)(3)(i)

The revised evaluation standard requires performing written technical and nontechnical evaluation(s) before making changes in the environment or operations that may affect the confidentiality, integrity, or availability of ePHI. Evaluations look at specific changes that regulated entities intend to make.

The Department proposes to delete the language “based initially on the standards implemented under this rule”. Evaluations assess the effects of planned changes compared to the environment reflected in the risk analysis. In other words, evaluations assess whether planned changes will create new security risks. They compare the change against the current security setup rather than regulatory text.

The Department proposes two new implementation specifications for the evaluation standard. Regulated entities that satisfy the underlying implementation specifications achieve the Evaluation standard.

Performance § 164.308(a)(3)(ii)(A)

A new performance implementation specification requires regulated entities to conduct the evaluation before making the change. NCVHS called this step Test to Produce Evidence of Compliance. Testing should occur at every significant change throughout the life of the system.

Preceding authoritative mappings of the Evaluation requirement to NIST SP 800-53 focused on Security Assessment controls (Control Assessments, Plan of Action and Milestones, Authorization, and Continuous Monitoring). The performance implementation specification bears much closer resemblance to Configuration Management Impact Analysis:

‍CM-4: Analyze changes to the system to determine potential security and privacy impacts prior to change implementation.

Response § 164.308(a)(3)(ii)(B)

The response implementation specification requires regulated entities to respond to the evaluation in accordance with its risk management plan. This implementation specification closely resembles RA-7 Risk Response from NIST SP 800-53:

‍Organizations have many options for responding to risk. This includes mitigating risk, accepting risk, sharing or transferring risk, or avoiding risk. The risk tolerance of the organization influences risk response decisions and actions. An entry into a plan of action documents mitigations not immediately completed.

Patch Management § 164.308(a)(4)(i)

A new patch management standard requires written policies and procedures for patching and updating system configurations. Timely implementation of patches is crucial for deterring exploitation of known vulnerabilities. 

The Department proposes six new implementation specifications for the patch management standard. Regulated entities that satisfy the underlying implementation specifications achieve the patch management standard.

Policies and Procedures § 164.308(a)(4)(ii)(A)

A new policies and procedures implementation specification requires timely mitigation of known vulnerabilities. This includes identifying, prioritizing, acquiring, installing, evaluating, and verifying patches, updates, and upgrades.

Regulated entities should pay careful attention to cybersecurity alerts describing newly discovered vulnerabilities. These alerts often include information on mitigation activities and patching. Patching, updating configurations, or upgrading the product can often mitigate known vulnerabilities.

The patch management standard aligns with the Department's enhanced CPG for Cybersecurity Mitigation. Regulated entities should prioritize and mitigate vulnerabilities discovered by scans and penetration tests.

Maintenance § 164.308(a)(4)(ii)(B)

A new maintenance implementation specification requires reviewing patch management policies and procedures. Reviews should occur at least once every 12 months. Regulated entities should modify them as reasonable and appropriate based on that review.

Application § 164.308(a)(4)(ii)(C)

A new application implementation specification requires patching, updating, and configuration upgrades based on risk analyses, vulnerability scans, monitoring of authoritative sources, and penetration tests. The NIST National Vulnerability Database (NVD) created the Common Vulnerability Scoring System (CVSS). The CVSS normalizes and ranks the severity of a vulnerability.

Regulated entities must take actions within an appropriate period of time, except when an exception applies. The Department specifies 15 calendar days as an appropriate period of time to mitigate a critical risk. Regulated entities would have 30 calendar days to mitigate a high risk. When patches, updates or upgrades are unavailable, the period of time starts when a mitigation becomes available. Regulated entities should specify an appropriate period for all other mitigations.

Exceptions § 164.308(a)(4)(ii)(D)

A new exception implementation specification requires documenting exceptions based on the following conditions:

1. A patch, update, or upgrade to the configuration is unavailable to address the risk.
2. The mitigation would adversely affect the confidentiality, integrity, or availability of ePHI. Regulated entities can determine this through their own testing of a patch, update, or upgrade. They can also rely on reports from government sources or knowledgeable cybersecurity professionals.

Alternative measures § 164.308(a)(4)(ii)(E)

A new alternative measures implementation specification requires real-time documentation of the exceptions and appropriate implementation of compensating controls.

Compensating controls § 164.308(a)(4)(ii)(F)

A new compensating controls implementation specification uses temporary security measures to address the risk. Such actions could include modifications of configuration files or disabling of affected services. The timeliness requirements are commensurate with the application of mitigations described above.

Risk Management § 164.308(a)(5)(i)

The Department proposes to elevate risk management implementation specification to a standard. Regulated entities must establish and implement a plan for reducing identified risks. The plan establishes appropriate levels of risk depending on the regulated entity’s:

• size 
• needs and capabilities 
• risk profile
• ability to reduce or eliminate an identified risk or vulnerability
• ubiquity of such security measures. 

The Department proposes four new implementation specifications for the risk management standard. Regulated entities that satisfy the underlying implementation specifications achieve the risk management standard.

Planning § 164.308(a)(5)(ii)(A)

A new planning implementation specification requires establishing and implementing a written risk management plan. The plan should reduce risks to ePHI identified by the risk analysis to an appropriate level. The risk assessment processes should inform the implementation of security measures. Risk management plans should address risk appetite, risk tolerance, workforce duties, responsible parties, the frequency of risk management, and required documentation.

A risk analysis generally provides a rating of applicable threat and vulnerability pairs. Regulated entities need to determine what risk rating poses an unacceptable level of risk to ePHI. Risk management plans should address any risks above the organization's risk tolerance. This requirement closely resembles PM-9 from the privacy baseline of NIST SP 800-53:

‍Risk management strategy includes an expression of the security and privacy risk tolerance. The accountable risk management official aligns information security management with operational and budgetary planning processes. Security and privacy risk-related inputs inform a comprehensive risk management strategy.

Regulated entities must document the implementation of appropriate security controls. Two other NIST SP 800-53 controls operationalize a written risk management plan:

• CA-5 Plan of Action and Milestones. Tracks planned remedial actions to reduce or eliminate known vulnerabilities in the system
• PL-2 System Security and Privacy Plans. Documents the controls selected to satisfy the requirements of the system. The plan describes each selected control with sufficient detail to assess its effectiveness.

K2 GRC's task tracking can help you assign remediation tasks and deadlines against your written risk management plan.

Maintenance § 164.308(a)(5)(ii)(B)

A new maintenance implementation specification requires reviewing the risk management plan at least every 12 months. Regulated entities may review the plan in response to changes in their risk analysis. Risk management activities should be performed with regular frequency. The activities include examining past decisions, reevaluating likelihood and impact levels, and assessing the effectiveness of remediations.

Priorities § 164.308(a)(5)(ii)(C)

A new priorities implementation specification requires prioritizing risks identified by the analysis. This closely resembles PM-4 Plan of Action and Milestones Process from NIST SP 800-53:

‍Review plans of action for consistency with risk management strategy and organization-wide priorities.

Implementation § 164.308(a)(5)(ii)(D)

The implementation specification requires establishing timely security measures to address identified risks. These security measures should be prioritized in accordance with (a)(5)(ii)(C).

Sanction policy § 164.308(a)(6)(i)

The Department proposed elevating the sanction policy implementation specification to a standard. Applying appropriate sanctions serves as an important tool for improving compliance by workforce members. 

Although there are no modifications to the language of the standard, there are three new implementation specifications. Regulated entities that satisfy the underlying implementation specifications achieve the sanction policy standard.

Policies and procedures § 164.308(a)(6)(ii)(A)

A new policies and procedures implementation specification requires sanctioning workforce members who violate security policies and procedures. Access agreements within general or security and privacy policies typically describe sanctions processes. 

Modifications § 164.308(a)(6)(ii)(B)

A new modifications implementation specification requires reviewing sanctions policies and procedures at least every 12 months. Regulated entities may review and modify sanction policies and procedures more frequently as appropriate.

Application § 164.308(a)(6)(ii)(C)

A new application implementation specification requires documenting the circumstances in which it applies sanctions.

Information system activity review § 164.308(a)(7)(i)

The Department elevated the information system activity review implementation specification standard. Regulated entities must regularly review the activity occurring in its relevant information systems. This review should identify inappropriate use or disclosure of ePHI. Written policies and procedures should define specific actions to quickly respond to suspicious activity. 

The Department proposed six implementation specifications to provide regulated entities with guidance on this standard. Regulated entities that satisfy the underlying implementation specifications achieve the information system activity review standard.

Policies and procedures § 164.308(a)(7)(ii)(A)

The policies and procedures implementation specification governs retaining and reviewing records of activity and responding quickly to any suspicious activity. 

Organizations should regularly review activity in their systems to identify suspicious activity. Operating procedures should include the types of audit data and monitoring procedures needed to derive exception reports. Activity reviews should include employees and vendors who have access to critical systems and data. Suspicious activities may include traffic to an unauthorized website, downloading data to an external device, or access to a network server by an unauthorized mobile device. 

Procedures should be customized to consider the capabilities of information systems with ePHI. Department guidance recommends considering the following when establishing policies and procedures for reviewing activity:

• What are the audit and activity review functions of the current information systems?
• Are system functions adequately used and monitored to promote continual awareness of activity?
• What logs or reports do the systems generate?
• Is there a policy that establishes what reviews will be conducted?
• Is there a procedure that describes the specifics of the reviews?
• Who is responsible for the overall process and results?
• How often are the results analyzed?
• Where will audit information reside (e.g., separate server)? 
• Is the information stored external to the organization ( e.g., cloud service provider)?

Scope § 164.308(a)(7)(ii)(B)

According to the scope implementation specification, activity records of persons and technology assets should include:

• audit trails
• event logs
• firewall logs
• system logs
• data backup logs
• access reports
• anti-malware logs
• security incident tracking reports. 

Record review § 164.308(a)(7)(ii)(C)

The record review implementation specification documents activity record reviews. Activity reviews of persons and technology assets should occur as often as appropriate for each type of report or log. Written policies and procedures should specify the review frequencies for each type of record.

Larger entities may adopt automated solutions that perform rules-based log aggregation and analysis to identify suspicious patterns in real-time and send alerts. Smaller entities might have designated staff that manually review log files and audit trails multiple times per week.

Record retention § 164.308(a)(7)(ii)(D)

The record retention implementation specification requires retaining activity records for an appropriate amount of time for each type of log. For example, it may be appropriate to retain audit trails for a different amount of time than security incident tracking reports.

Response § 164.308(a)(7)(ii)(E)

The response implementation specification establishes responses to suspected security incidents identified during activity reviews within the security incident plan.

Maintenance § 164.308(a)(7)(ii)(F)

The maintenance implementation specification requires reviewing and testing activity reviews policies and procedures at least every 12 months. Regulated entities should modify policies and procedures as appropriate based on the results of that review.

Assigned security responsibility § 164.308(a)(8)(i)

The updated assigned security responsibility standard requires regulated entities to identify the Security Official in writing. The Security Official responsibilities include implementing policies, procedures, and technical controls. This is comparable to the designation of a Privacy Official within the Privacy Rule. The Security Official and Privacy Official can be the same person, but they do not need to be. Specific security responsibilities may still be assigned to other workforce members.

The Security Official should be able to assess the effectiveness of security. Regulated entities should document the responsibilities in a job description and communicate this role assignment to the organization.

There are no supporting implementation specifications for this standard. Regulated entities must fulfill the requirements to achieve the assigned security responsibility standard.

K2 GRC's task list and evidence repository can help you schedule the annual audit and keep supporting documentation in one place.

Workforce security § 164.308(a)(9)(i)

The updated workforce security standard ensures that workforce members have appropriate access to ePHI, relevant systems and physical facilities and prevents unauthorized access.

The Department proposes five implementation specifications to provide regulated entities with additional guidance. Regulated entities that satisfy the underlying implementation specifications achieve the workforce security standard.

Authorization and/or supervision § 164.308(a)(9)(ii)(A)

The authorization and/or supervision implementation specification provides checks and balances to ensure access to ePHI is appropriate. Access authorization is the process of determining whether a user or a computer system has the right to carry out a certain activity. 

HHS guidance instructs regulated entities to identify workforce members who need access to ePHI to carry out their duties. Covered entities must identify the ePHI authorized for relevant job functions. Access controls should limit the ePHI for each workforce member or job function. This includes computer systems and applications that provide access to the ePHI. Regulated entities should limit access to ePHI to that which is necessary for a workforce member to do their job. HHS provided some basic questions to determine appropriate authorization and/or supervision procedures:

• Are job description details used to determine ePHI access?
• Who has or should have the authority to determine who can access ePHI (e.g., supervisors or managers)
• Are there similar existing processes used for paper records that could be used as an example for the 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?

Small medical practices may allow all staff members to access all ePHI because staff members may perform multiple functions. In this case, the regulated entity would document the reasons for permitting this type of global access.

Workforce clearance procedure § 164.308(a)(9)(ii)(B)

The updated workforce clearance procedure implementation specification requires screening employees to determine whether access to ePHI or relevant information systems is appropriate. A regulated entity may choose to perform screening separate from, or as a part of, the authorization and/or supervision procedure. NIST recommends establishing hiring criteria and provides questions to consider:

• 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? 

Modification and termination procedures § 164.308(a)(9)(ii)(B)

The modification and termination procedures extend the scope of terminating ePHI access to relevant information systems and facilities. This implementation specification requires terminating access as soon as possible, but no later than one hour after the workforce member's employment or other arrangement ends.

The Department's 2019 guidance recognized that security is a dynamic process. Data access privileges should be re-evaluated when promoting, demoting, or transferring a user. Standard procedures containing off boarding action items prevents unauthorized access to ePHI. Such actions should include:

• disabling the user's computer and application accounts
• deactivate computer access (e.g.,disable user IDs and passwords)
• Deactivate facility access (changing facility access codes known to the user) 
• recover access control devices (e.g., identification badges, keys, access cards)

Notification § 164.308(a)(9)(ii)(D)

A new notification implementation specification requires notifying other regulated entities of a change in, or termination of, a user's authorization to access ePHI or relevant information systems. Regulated entities must provide notices as soon as possible, but no later than 24 hours after changing or terminating the workforce member's authorization to access ePHI or relevant information systems.

Maintenance § 164.308(a)(9)(ii)(E)

A new maintenance implementation specification requires reviewing and testing workforce security policies and procedures at least every 12 months. Regulated entities should modify workforce security policies and procedures as appropriate. 

Information access management § 164.308(a)(10)(i)

The revised information access management standard harmonizes access authorizations to ePHI and relevant information systems with the Privacy Rule. Restricting access to entities with an established need minimizes the risk of inappropriate disclosure, alteration, or destruction of ePHI.

The Department proposes to modify three of the existing implementation specifications and adds three new specifications. Regulated entities achieve the information access management standard by satisfying these six implementation specifications.

Isolating health care clearinghouse functions § 164.308(a)(10)(ii)(A)

The implementation specification for isolating health care clearinghouse functions still requires a health care clearinghouse that is part of a larger organization to protect ePHI from unauthorized access by the larger organization. The modification clarifies extends these requirements to relevant information systems as well.

Regulated entities must determine whether its components constitute a health care clearinghouse. A health care clearinghouse means:

‍a public or private entity, including a billing service, repricing company, community health management information system or community health information system, and “value-added” networks and switches, that does either of the following functions:

(1) Processes or facilitates the processing of health information received from another entity in a nonstandard format or containing nonstandard data content into standard data elements or a standard transaction.

(2) Receives a standard transaction from another entity and processes or facilitates the processing of health information into nonstandard format or nonstandard data content for the receiving entity.

The regulated entity should document if no health care clearinghouse functions exist. If a health care clearinghouse does exist, they must implement procedures consistent with the Privacy Rule. Questions for regulated entities to consider include: 

• If health care clearinghouse functions exist, is ePHI protected from the other functions of the 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 the organization established a separate network or subsystem for the health care clearinghouse?
• Has the organization trained health care clearinghouse staff to safeguard ePHI from disclosure?
• What technical safeguards separate ePHI in systems used by the health care clearinghouse to protect against unauthorized access?

Access authorization § 164.308(a)(10)(ii)(B)

The access authorization implementation specification grants access to ePHI as appropriate for users to carry out their assigned function(s). The modification extends the scope from users to technology assets and from ePHI access to include relevant information systems.

Authentication management § 164.308(a)(10)(ii)(C)

A new authentication management implementation specification verifies the identities of users and technology assets before accessing the regulated information systems. This specification includes new requirements for implementing multifactor authentication (MFA).

Access determination and modification § 164.308(a)(10)(ii)(D)

The Department renamed the access establishment and modification implementation specification access determination and modification.This specification determines, documents, reviews, and modifies user and non-person technology asset access to specific components of the system.

Regulated entities must establish standards for granting access to ePHI and relevant systems. They must provide formal authorization from the appropriate authority before granting access. Regulated entities should regularly review access to ePHI and relevant systems to validate and modify access as needed.

NIST guidance outlines steps for granting access to ePHI as follows:

• Decide and document procedures for how access to ePHI would be granted to workforce members within the organization.
• Select the basis for restricting access to ePHI. 
• Select an access control method (e.g., identity-based, role based, or other appropriate means).
• 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 should 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.
• Are appropriate authorization and clearance procedures 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? 
• Are organizational personnel authorized to approve user requests to access ePHI and/or systems with ePHI?

Network segmentation § 164.308(a)(10)(ii)(E)

A new network segmentation implementation specification ensures segmentation of relevant systems to limit ePHI access to authorized workstations.

Maintenance § 164.308(a)(10)(ii)(F)

The maintenance implementation specification requires reviewing the policies and procedures at least every 12 months. Regulated entities should modify information access management policies and procedures as appropriate.

Security Awareness Training § 164.308(a)(11)(i)

The Department renamed the security awareness and training standard to security awareness training. Security awareness training should cover the protection of ePHI and information systems as necessary and appropriate for the members of the workforce to carry out their assigned function(s). 

An organization's training program should be an ongoing, evolving process and flexible. It should educate workforce members on new cybersecurity threats and how to respond to them. Regulated entities should consider how often to train workforce members and how often to send security updates. Many have determined that twice-annual training and monthly security updates are necessary.

Security updates and reminders can quickly communicate new and emerging cybersecurity threats such as new social engineering ploys and ransomware variants. Entities address what type of training to provide given the risks and threats to their enterprises. Computer-based training, classroom training, monthly newsletters, posters, email alerts, and team discussions are all training tools. Entities must also address how to document training participation, including dates and types of training.

The Department proposes four implementation specifications for this standard. Regulated entities achieve the security awareness training standard by satisfying the implementation specifications.

Training § 164.308(a)(11)(ii)(A)

The training implementation specification requires security awareness training for all workforce members addressing:

The written policies and procedures necessary for the workforce to carry out their assigned functions. This aligns with the Basic Cybersecurity Training CPG requiring educating users on how to access ePHI in a manner that protects the confidentiality, integrity, and availability. Program elements might include the following: 

• An onboarding and training program, with outlined roles and responsibilities of the stakeholder 
• Development and distribution of cybersecurity awareness materials by the Cybersecurity Change Leader
• Regular touch points with Cybersecurity Change Leaders to promote communication and maintain relationships 
• Encouragement of feedback from the Cybersecurity Change Leader to the awareness team. Adjustment of outreach based on these recommendations, with special attention dedicated to understanding the best channels of cybersecurity awareness content

Guarding against, detecting, and reporting suspected incidents. This includes malicious software and social engineering. This aligns with the Email Security CPG by training the workforce to catch phishing and other social engineering attempts. Points to include in a successful training campaign include: 

• Sender verification: Users should carefully examine the sender of the email message. Educate users to lookout for emails where your organization’s name appears with a separate email domain.
• Follow the links: Every link in an email message is suspect. Organizations should limit the use of links in corporate messages to those that are necessary. Users should hover over each link to check the corresponding URL and determine whether it is credible. Specifically, mismatched URLs are highly suspect. 
• Beware of attachments. Though it can be difficult to determine whether an attachment is malicious based on the content of an email message, there are often clues. Be wary of messages that require immediate action. Be cautious when receiving attachments from senders with whom you do not regularly correspond. 
• Suspect content: In most cases, hackers entice recipients of email to follow a link or open an attachment. They will use messages to play with the natural curiosity and emotions of those receiving the email. 
• Avoid acting. BEC schemes typically encourage the recipient to take an action. These messages may impersonate a senior executive or key vendor/supplier. In many cases, they may require a quick action to avoid a penalty, lost deal, etc. Changes to account numbers, wire transfers, and requests to send sensitive information should be verified. Communicate with the sender based on known contact information.

The written policies and procedures for accessing the system. This includes safeguarding passwords, setting unique passwords, limiting password sharing, and prohibiting the use of default passwords.

Timing § 164.308(a)(11)(ii)(B)

The Department proposes to replace the security reminders with an implementation specifications addressing the timing and frequency of security awareness training:

1. Regulated entities must provide training to each member of their workforce by the compliance date for this rulemaking, and at least once every 12 months thereafter. 
2. Regulated entities must provide role-based security awareness training to new workforce members within a reasonable period of time. This should occur no later than 30 days after the workforce member first has access to the relevant information systems. 
3. Regulated entities must provide security awareness training on a material change to the policies or procedures. This should include any member of the workforce whose functions are affected by such change. Training should occur, within a reasonable period of time but no later than 30 days after the change occurs.

Ongoing education § 164.308(a)(11)(ii)(C)

A new implementation specification for ongoing education provides workforce members with ongoing reminders of their security responsibilities and notice of relevant threats. This includes new and emerging malicious software and social engineering.

Documentation § 164.308(a)(11)(ii)(D)

A new implementation specification for maintenance requires documenting training and ongoing reminders provided to the workforce.

Security incident procedures § 164.308(a)(12)(i)

The Department revised the security incident procedures standard to “respond to” rather than simply “address” security incidents. Planning and continuous monitoring mitigate the negative effects of incidents. 

A well thought-out, well-tested security incident response plan is integral to ensuring the security of ePHI. A timely response to a security incident can be one of the best ways to prevent, mitigate, and recover from future cyberattacks. NIST offers guidance for addressing security incidents:

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

The Department proposes two implementation specifications under the security incident procedures standard. Regulated entities achieve the security incident procedures standard by satisfying these implementation specifications.

Planning and testing § 164.308(a)(12)(ii)(A)

A new planning and testing implementation specification requires regulated entities to: 

1. document how workforce members report suspected security incidents and how the regulated entity will respond;
2. implement written procedures for testing and revising the security incident response plan(s), and 
3. review and test security incident response plans at least every 12 months and document the results of such tests. 

Response § 164.308(a)(12)(ii)(B)

The Department renamed the response and reporting implementation specification response and separated it into five paragraphs:

1. Identify and respond to suspected or known security incidents. The first response to any cyber-attack is to understand the scope and extent of the attack. The identification phase of an attack response involves categorizing and classifying components of the attack based on your policies and procedures.
2. Mitigate, to the extent practicable, suspected or known harmful effects of security incidents. After understanding the extent and scope of the attack, the next step is to contain the attack.
3. Identify and remediate, to the extent practicable, the suspected or known root cause(s) of security incidents.
4. Eradicate the suspected or known security incidents. This phase focuses on eliminating all traces of the attack, including the attack foothold. 
5. Develop and maintain documentation of suspected and known security incident investigations, analyses, mitigation, and remediation. Under proposed 45 CFR 164.316(b)(1), maintain such documentation for six years from the date of its creation or the date when it last was in effect, whichever is later.

This specification aligns with the Basic Incident Planning and Preparedness CPG to effectively respond to and recover from security incidents. Generally, a structured incident response process contains the following segments: 

• Preparation: Establish policies, processes, and procedures including the following components: 
  
  • IR policy. A policy that defines: 
    
    • the categorization and severity of incidents 
    • the stakeholders involved in IR
    • the roles and responsibilities of each person
    • the entry criteria when a security incident occurs
    • the person who oversees IR plays. 
  • Cybersecurity incident response team (CIRT). A pre-formed group that knows how to navigate issues when security incidents arise. This team develops and manages your organization’s response. The incident commander is the most senior official overseeing managing cybersecurity incidents. The incident commander is usually the Chief Information Security Officer (CISO) or equivalent. Note that the incident commander should not dive into the technical weeds of the incident, rather keep the various teams organized and focus on their objectives.

Contingency plan § 164.308(a)(13)(i)

The revised contingency plan standard requires establishing a contingency plan. This plan consists of policies and procedures for responding to an emergency. Emergencies may include fire, vandalism, system failure, natural disaster, or security incidents. The plan should protect resources, minimize customer inconvenience, and assign recovery responsibilities to key staff. 

The Department proposes six implementation specifications for the contingency plan standard. Regulated entities achieve the contingency plan standard by satisfying the underlying implementation specifications.

Criticality analysis § 164.308(a)(13)(ii)(A)

The Department replaced the applications and data criticality analysis implementation specification with criticality analysis. Regulated entities must document an assessment of the relative criticality of its systems and technology assets.

The proposal would extend the scope of the existing implementation specification. It would include systems that handle ePHI and other systems and/or technology assets crucial to ensuring the security of ePHI, providing patient care, and supporting other business needs. A prioritized list of systems and technology assets should inform the order of their restoration.

Data backups § 164.308(a)(13)(ii)(B)

The Department renamed the data backup plan implementation specification data backups. Written procedures to create and maintain exact retrievable copies of ePHI must now include verifying the integrity of ePHI. 

Information systems backups § 164.308(a)(13)(ii)(C)

A new information systems backup implementation specification requires creating and maintaining backups of relevant systems. Written procedures should include verifying the success of backups.

Disaster recovery plan § 164.308(a)(13)(ii)(C)

The Department revised the disaster recovery plan implementation specification to require:

1. establishing written procedures to restore critical systems and data within 72 hours of the loss, and
2. restoring the loss of other relevant systems and data in accordance with its criticality analysis.

Emergency mode operation plan § 164.308(a)(13)(ii)(D)

The Department revised the emergency mode operation plan implementation specification. Written procedures for operating in emergency mode must address the protection of ePHI.

Testing and revision procedures § 164.308(a)(13)(ii)(E)

The Department revised the testing and revision procedure implementation specification to clarify that:

1. Procedures for testing and revising of contingency plans must be established in writing. 
2. Regulated entities must review and test their testing procedures at least every 12 months. Results of such reviews and tests should be documented. Regulated entities should modify plans as appropriate based on the test results.

Compliance audit § 164.308(a)(14)(i)

The Department proposed renaming the evaluation standard compliance audit. Regulated entities must document an audit of their compliance with each standard and implementation specification at least every 12 months. The audit should be performed by the regulated entity or an external party.

There are no supporting implementation specifications for this standard. Regulated entities must fulfill the requirements defined in the standard.

Business associate contracts and other arrangements § 164.308(b)(1)

The proposed business associate contracts and other arrangements standard requires regulated entities to obtain satisfactory assurances that business associates comply with the Security Rule. This includes verifying business associates have deployed the required technical safeguards.

Regulated entities may include more stringent cybersecurity measures. Such requirements need to be agreed upon by both parties within a business associate agreement. NIST recommends a process for measuring contract performance and terminating those failing to meet security requirements. Important considerations include: 

• What is the service being performed?
• What is the expected outcome?
• Is there a process for reporting security incidents related to the agreement? 
• Are additional assurances of ePHI protections from the business associate necessary? If so, where and how does the regulated entity document additional assurances?

The Department proposes two implementation specifications for the business associate contracts and other arrangements standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Written contract or other arrangement § 164.308(b)(2)(i)

The revised written contract or other arrangement implementation specification requires documenting assurances through a written contract or other arrangement. These assurances document the business associate meets the applicable requirements of § 164.314(a).

Written verification § 164.308(b)(2)(i)

A new implementation specification requires obtaining written verification that the business associate has deployed the required technical safeguard at least every 12 months. A person with appropriate knowledge of and experience must perform an accurate written analysis of the business associate’s relevant systems.

K2 GRC's third-party risk management service helps you track and monitor third-party risk, which supports the annual written verification this specification calls for.

Delegation to business associate § 164.308(b)(3)

A new delegation standard clarifies that regulated entities may permit a business associate to serve as its designated security official. Regulated entities delegating actions, activities, or assessments to business associates remain liable for compliance with all applicable provisions of the Security Rule.

There are no supporting implementation specifications for this standard. Regulated entities must fulfill the requirements to achieve the compliance audit standard.

Crosswalk Resource

We created this crosswalk resource by reading through each proposed standard and implementation specification. The Department often identified corresponding safeguards from the current Security Rule. We prompted Gemini to evaluate the nature of the relationship between the related concepts using the Supportive Relationship mapping style. This process determined whether supporting concepts from 2013 requirements satisfied the updated 2027 requirements. The resource contains the results of this analysis within the column H. Other supporting columns include:

• Column A: 2027 HIPAA Security Rule Section identifier
• Column B: 2027 HIPAA Domain
• Column C: 2027 Standard
• Column D: 2027 Implementation Specification Name
• Column E: 2027 HIPAA Implementation Specification Description
• Column F: 2013 HIPAA Section identifier
• Column G: 2013 HIPAA Requirement Description
• Column H: Gemini categorization of relationship based on NIST IR 8477

How K2 GRC Can Help You Prepare

The proposed rule is not final, and the current Security Rule remains in effect. But the proposed changes center on written documentation and recurring 12-month reviews, and starting now gives you time to close gaps before a final rule publishes. Depending on where you are, there are a few ways K2 GRC can help:

• Start with the gap analysis. Download the full HIPAA Security Rule Crosswalk 2013 to 2027 Spreadsheet to see which requirements are fully met, partially met, or new.
• Build the documentation. K2 GRC combines policy templates, a task list, and training in one platform, so you can write the policies the proposed rule calls for and set up 12-month review cycles.
• Talk to our team. Contact K2 GRC to see how the platform can support your preparation. Contact K2 GRC to see how the platform can support your preparation.

‍