By the EHR Association Privacy & Security Workgroup

This three-part blog series shares the EHR Association’s stance on OCR’s proposed changes to the HIPAA Security Rule. Part one focused on our overarching concerns and issues with proposed definitions. Part two and this installment highlight our concerns with OCR’s proposed expectations. 

The HIPAA Security Rule is overdue for modernization, given the rapid pace of technological change and increasing cybersecurity threats. While we support OCR’s intent to strengthen protections for electronic protected health information (ePHI), our analysis of the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information raised concerns and questions we hope will be addressed before finalization.

In the previous installment of this blog series, we outlined our concerns with several of OCR’s proposed expectations, highlighting the need for greater clarity and offering recommendations to ease compliance burdens while achieving the intended outcomes. We finalize that discussion in this installment, beginning with Section 164.312(b)(1)—Standard: Encryption and Decryption.

Guidance Needed, Alignment Recommended

The EHR Association generally supports encryption as a best practice for data at rest and in transit. However, hardware and performance implications must be considered to strike a balance between security and system efficiency. OCR should provide clear guidance on acceptable encryption levels within a system without incurring unnecessary hardware expenditures or performance costs. Balancing security and system efficiency is critical. 

Aligning regulatory expectations with industry best practices will help regulated entities ensure effective security management without imposing unnecessary operational burdens.

We also recommend that OCR clarify the distinction between “testing” and “auditing” in the Configuration Management requirements (Section 164.312(c)(1)—Standard: Configuration Management). Testing evaluates the effectiveness of technical controls, while auditing ensures they are appropriately implemented and maintained. Aligning regulatory expectations with industry best practices will help regulated entities ensure effective security management without imposing unnecessary operational burdens.

We believe clarification is needed from OCR in several additional areas:

• Section 164.312(d)(1)—Standard: Audit Trail and System Log Controls: OCR should clarify whether audit trail and system log control requirements apply to all systems or if implementation should be prioritized based on system criticality to patient care. A risk-based approach focused on systems impacting safety and clinical decision-making would reduce unnecessary operational and financial burdens. When establishing compliance timelines, OCR should also consider the substantial time and resources needed for implementation.
• Section 164.312(f)(1)—Standard: Authentication: Multi-Factor Authentication: We support multi-factor authentication (MFA) as a best practice, but the burden it can place on end-users if the requirements are extended too far or too granularly and related cost implications for regulated entities should be considered. Requiring it universally without flexibility will necessitate substantial investments in new hardware and infrastructure, as many organizations do not permit the use of personal devices for authentication. Rather than a blanket requirement, OCR should require organizations to document their risk analysis and implement MFA where it provides significant security benefits. This ensures both security and operational feasibility.
• Section 164.312(h)(1)—Standard: Vulnerability Management: Expectations for vulnerability management, patching, and penetration testing should align with NIST and other industry standards to ensure consistency and feasibility for regulated entities. This will help organizations effectively prioritize updates while balancing operational stability and security.

A unified “technical control testing” framework that consolidates testing requirements across the Security Rule should also be considered. Penetration testing could be a comprehensive evaluation by incorporating elements of vulnerability management, system monitoring, and patch management. This strategy could reduce redundant compliance burdens while still ensuring robust security assessments. Further, a risk-based approach tailored to system criticality would enhance security without imposing excessive costs or resource demands.

Risk-Based Data Backup and Recovery

We support robust backup and recovery practices but recommend flexibility based on system criticality and the role of different entities in managing ePHI (Section 164.312(i)(1)—Standard: Data Backup and Recovery). 

The proposed 48-hour data retrieval requirement should … differentiate expectations based on system criticality and whether an entity is a Covered Entity or Business Associate. This ensures compliance efforts align with actual operational and patient care needs.

The proposed 48-hour data retrieval requirement should consider varying use cases, as not all backups serve the same function. For example, clinical care systems require more immediate availability than research or support systems. Thus, the requirement should differentiate expectations based on system criticality and whether an entity is a Covered Entity or Business Associate. This ensures compliance efforts align with actual operational and patient care needs.

Finally, while real-time monitoring and monthly restoration testing are good practices, organizations should have flexibility in how backup integrity is validated based on risk assessments. Alternate approaches should be allowed to ensure recoverability without imposing unnecessary burdens, particularly for downstream systems that do not need continuous availability. A flexible, risk-based approach would best provide reliable data recovery while balancing resource constraints and technical feasibility.

The EHR Association’s complete feedback to OCR on its proposed HIPAA Security Rule can be found here.