The US Department of Health and Human Services (HHS) is preparing the most significant overhaul of the HIPAA Security Rule in more than a decade. The proposed rule, formally titled the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information, would introduce far more detailed requirements for protecting electronic protected health information, or ePHI.
The federal regulatory agenda currently targets July 2027 for final action. That date remains an agency planning target rather than a guaranteed publication date, and the final requirements may differ from the proposal.
Organisations covered by HIPAA should begin to assess their existing arrangements. Many of the proposed requirements reflect security practices that HHS already considers necessary for an effective HIPAA compliance programme, and identifying existing gaps now can help ensure you are on top of the requirements ahead of time.
When would the new HIPAA Security Rule take effect?
Although HHS is targeting final action in July 2027, this does not necessarily mean that regulated organisations will have to comply from that date. Under the proposal, the final rule would become effective 60 days after publication. Covered entities and business associates would generally then have 180 days from the effective date to implement the new or modified requirements.
If a final rule were published in July 2027 and retained this timetable, the principal compliance deadline would probably fall in early 2028. HHS could change the implementation period when it issues the final rule, and some contractual provisions may receive a longer transition period.
Until then, the existing Security Rule remains in force. Organisations must continue complying with its current administrative, physical and technical safeguard requirements.
What would the new HIPAA Security Rule change?
The proposal represents a move towards a more prescriptive and auditable cybersecurity standard. The current rule allows organisations to take their size, complexity, technical infrastructure and resources into account when deciding how to implement certain safeguards. Some implementation specifications are described as “addressable”, allowing an organisation to determine whether a particular control is reasonable and appropriate in its circumstances.
HHS proposes to remove the distinction between “required” and “addressable” implementation specifications. Almost every implementation specification would become mandatory, subject only to specific and limited exceptions. Organisations would retain some flexibility over how controls are deployed, although deciding that implementation is unnecessary would generally cease to be an option.
Technology asset inventories and ePHI mapping
Covered entities and business associates would have to maintain a technology asset inventory identifying the systems and devices that may affect the confidentiality, integrity or availability of ePHI.
They would also need a network map illustrating how ePHI moves through their electronic information systems. The inventory and map would have to be reviewed and updated on an ongoing basis, at least once every 12 months and following relevant changes to the organisation’s systems, environment or operations.
For many organisations, this will require visibility beyond core electronic health record systems. Relevant assets may include:
- Cloud infrastructure and software-as-a-service platforms
- Medical and diagnostic devices
- Employee workstations and mobile devices
- Billing, claims and scheduling systems
- Backup environments
- Interfaces with laboratories, pharmacies and other providers
- Systems operated by business associates and subcontractors
An incomplete inventory will undermine almost every other part of the proposed framework. An organisation cannot conduct a comprehensive risk analysis, apply encryption consistently or verify access rights unless it knows where its ePHI is created, received, maintained and transmitted.
The proposal makes clear that a proper HIPAA risk analysis already requires organisations to understand their technology assets and the movement of ePHI. The new provisions would make those expectations explicit in the regulatory text.
More detailed security risk analyses
Risk analysis has long been central to the HIPAA Security Rule. The proposed rule would specify what that analysis must contain and how it should be documented.
A compliant written assessment would need to consider the organisation’s asset inventory and network map, identify reasonably anticipated threats and vulnerabilities, assess the likelihood of exploitation and determine the potential impact on ePHI.
The analysis would need to cover the full environment in which ePHI is handled. This includes remote devices, third-party platforms, network connections and systems that may not contain ePHI themselves yet remain important to its security or availability.
Risk management would also need to become a traceable process. Organisations would be expected to document:
- The risks identified
- The controls selected to address them
- Responsibility for remediation
- Decisions to use compensating controls
- The reasoning behind those decisions
- Evidence that remediation has been completed and tested
Purchasing a cybersecurity product or commissioning a periodic technical assessment will not, by itself, amount to a HIPAA risk analysis. HHS has repeatedly found that organisations relied on fragmented vendor reports without conducting a holistic assessment of all the ePHI for which they were responsible.
Encryption, MFA and technical security controls
Several controls that are currently framed flexibly would become express requirements. The proposal would require encryption of ePHI both at rest and in transit, subject to limited exceptions. It would also introduce a broad requirement for multi-factor authentication when accessing relevant electronic information systems.
Other proposed technical requirements include:
- Network segmentation to restrict access and prevent an intrusion from spreading across the organisation
- Anti-malware protection
- Removal of unnecessary software
- Disabling unnecessary network ports
- Secure and consistent system configurations
- Vulnerability scanning at least once every six months
- Penetration testing at least once every 12 months
- Separate technical controls for backing up and recovering ePHI and relevant systems
- Regular review of audit trails, system logs, firewall logs, access reports and security incident records
The proposal would require organisations to put technical controls into operation and verify that they continue to operate. A policy stating that access is restricted or data is encrypted will not be enough where the corresponding control has not been deployed across the relevant environment.
Compliance teams will need reliable evidence from IT and security functions showing that controls are active, correctly configured and regularly tested.
Incident response, backups and operational resilience
Organisations would have to perform a documented criticality analysis identifying which systems and technology assets should be restored first following an incident. They would also need written procedures capable of restoring critical systems and data within 72 hours of a loss. Other systems would have to be restored according to the priorities identified through the criticality analysis.
Contingency plans would need to address data backups, system backups, disaster recovery, emergency operations and incident response. Organisations would generally have to test their contingency arrangements at least annually, document the results and revise the plans where testing identifies weaknesses.
This will require more than a written disaster recovery plan. Organisations should be able to demonstrate that:
- Backups are complete and recoverable
- Restoration processes work within the required timeframe
- Staff know who may activate the contingency plan
- Clinical and operational priorities have been identified
- Dependencies on vendors and business associates have been tested
- Lessons from exercises and real incidents lead to documented improvements
Annual HIPAA Security Rule audits
Covered entities and business associates would be required to audit their compliance with every applicable Security Rule standard and implementation specification at least once every 12 months. The audit and its findings would have to be documented.
This creates a much stronger requirement for continuous assurance. A general cybersecurity assessment will not necessarily be sufficient. The audit should map evidence against the individual HIPAA requirements and identify any gaps, control failures or overdue actions.
Compliance teams should begin developing a control register that links each proposed requirement to:
- The responsible control owner
- The relevant policy and procedure
- The technical or organisational control
- Testing frequency
- Evidence of operation
- Identified gaps and remediation deadlines
Stronger oversight of business associates
The proposed rule would significantly increase the scrutiny applied to business associates and their subcontractors. At least annually, business associates would have to provide covered entities with written verification that they had deployed the required technical safeguards. This would have to be supported by an analysis performed by an appropriate subject matter expert and a written certification that the analysis had been completed and was accurate. Similar obligations would apply between business associates and their subcontractors.
Business associates would also have to notify covered entities without unreasonable delay, and no later than 24 hours after activating a contingency plan. The proposal leaves the parties free to agree the precise form and content of that notification through their business associate agreement.
Covered entities should expect to revise their due diligence, contracting and monitoring processes. Vendor questionnaires alone would likely not provide sufficient assurance. Compliance teams woulld need formal evidence of independent technical analysis, clearer rights to obtain documentation and escalation procedures when a business associate cannot provide the required verification.
Workforce access and security training
The proposal would formalise role-based security awareness training for all workforce members. Training would have to cover the organisation’s security policies, secure access to information systems, password practices and the identification and reporting of security incidents. It would expressly include malicious software and social engineering threats such as phishing and fraudulent support requests.
Training would generally have to be provided at least once every 12 months, with further training following relevant changes to policies, systems or workforce responsibilities. The organisation would need to retain evidence of the training provided and workforce participation.
Access management processes will also need closer coordination between HR, IT, compliance and third parties. Where an individual’s access to another regulated entity’s systems changes or ends, the proposal would require notification as soon as possible and no later than 24 hours.
What should HIPAA compliance teams do now?
The final rule may change, so organisations do not need to rewrite their entire compliance programme around every word of the proposal. Nevertheless, they can still make progress on areas that are already expected under HIPAA or represent established cybersecurity practice.
Conduct a structured gap analysis
Compare the existing security programme with the proposed requirements. Identify where controls are absent, inconsistently implemented or poorly documented. Particular attention should be given to encryption, MFA, asset management, network mapping, vulnerability management, penetration testing, incident response and annual assurance.
Establish clear ownership
HIPAA security cannot remain the sole responsibility of either the privacy team or the IT department. Compliance should coordinate a cross-functional programme involving information security, IT, privacy, legal, procurement, HR, operations, clinical leadership and business continuity. Each requirement should have a named owner with authority to implement controls and remediate deficiencies.
Improve the evidence trail
Organisations should begin consolidating policies, risk assessments, network diagrams, training records, testing reports, access reviews, vendor assurance and remediation evidence. The proposed rule places substantial emphasis on written documentation. Being able to demonstrate how a control operates will carry almost as much importance as having the control itself.
Prioritise controls with immediate security value
Encryption, MFA, secure backups, vulnerability scanning and access reviews address present-day risks and are unlikely to become irrelevant even if the final rule is amended. Where full implementation is difficult because of legacy systems or medical devices, the organisation should identify the risk, consider compensating controls and document a realistic replacement or remediation plan.
Review business associate arrangements
Create a complete register of business associates and subcontractors, identify the systems and ePHI involved, and assess whether current contracts provide adequate security assurance and incident notification rights. Organisations should also determine which vendors may struggle to provide annual technical verification and where alternative suppliers or enhanced oversight may be necessary.
Test recovery and incident response
Run exercises based on ransomware, cloud failure, vendor disruption and loss of critical clinical systems. Measure how long restoration actually takes rather than relying on estimated recovery times. Any inability to restore essential systems within 72 hours should be treated as a significant remediation issue under the proposed framework.
Update training for current threats
Annual general HIPAA training should be supplemented with practical content on phishing, social engineering, credential theft, ransomware, secure remote access and incident reporting. Training should reflect the risks associated with each role. System administrators, clinicians, remote workers, customer service staff and employees handling large volumes of ePHI will require different scenarios and instructions.
