The HIPAA Security Rule May Be Changing. Here’s What Sacramento Healthcare Organizations Should Know.

The target window for finalizing the proposed HIPAA Security Rule has already passed. A final rule has not been published, and as of June 2026, OCR Director Paula Stannard has not confirmed whether one is coming or in what form. More than 100 hospital systems and industry groups have called for the proposed rule to be withdrawn. The May 2026 window OCR had set for finalization closed with no announcement.

So why does this matter to Greater Sacramento healthcare organizations right now? Because uncertainty about the proposed rule does not suspend your obligations under the current one. The HIPAA Security Rule compliance deadline has been in force since 2005. OCR is actively investigating covered entities and issuing settlements. And OCR’s own director, speaking at the HIPAA Summit earlier this year, told healthcare organizations directly: there is a high cost of doing nothing. A cyberattack, she noted, can cost far more than compliance ever would, and OCR investigators may be the ones knocking on your door afterward.

The proposed rule matters because it describes the security posture the federal government is moving toward, regardless of exactly when or in what form a final rule arrives. For Greater Sacramento healthcare organizations, from independent medical practices and specialty clinics to behavioral health providers, dental offices, and home health agencies, the question is not whether to wait for regulatory certainty. It is whether your organization can demonstrate compliance with the rule already in force, and whether you will be positioned when the next version of it lands.

The 2003 Security Rule divided its implementation specifications into two categories: required specifications that had no flexibility, and addressable specifications that organizations could satisfy through alternative measures if the listed control was not reasonable and appropriate. In practice, the “addressable” designation became a mechanism for avoiding controls that were inconvenient rather than genuinely impractical. Encryption and multi-factor authentication were both addressable. OCR has publicly noted that the addressable concept has caused widespread confusion and inconsistency.

The proposed rule would eliminate that distinction. Every specification would be required. The practical effect is that controls previously deferred because they were “addressable” would become mandatory, with no alternative path. That includes encryption of electronic protected health information at rest and in transit, and technical controls for access verification that would satisfy a multi-factor authentication requirement.

Other significant proposals include requiring a formal written technology asset inventory and network map, mandating annual security risk analyses with specific documented elements, requiring covered entities to verify in writing that their business associates have implemented required security controls, establishing specific timelines for vulnerability scanning and penetration testing, and setting explicit patch management deadlines for critical and high-severity vulnerabilities.

Under the current Security Rule, encryption of electronic protected health information at rest and in transit is listed as an addressable implementation specification under two separate safeguard categories. Organizations are required to assess whether encryption is a reasonable and appropriate safeguard and, if they determine it is not, document that determination and implement an equivalent alternative measure. In practice, many organizations have made that determination without rigorous analysis and without implementing anything equivalent.

The proposed rule would eliminate this flexibility. Encryption would be required for ePHI stored on any electronic device or storage media, and for ePHI transmitted over any external network. For most Sacramento medical practices, this touches every laptop that could have patient data on it, every server in the back office, every cloud application that stores clinical records, and every email chain that includes any patient information. Older systems often lack native encryption capabilities. Systems that cannot be encrypted would require network segmentation at minimum or would need to be replaced.

The encryption requirement is not new in concept. OCR guidance from 2013 and 2017 both strongly recommended encryption as a baseline control. The proposed rule would convert that strong recommendation into a legal mandate.

The current Security Rule requires covered entities to implement procedures to verify that a person seeking access to ePHI is who they claim to be. Authentication has always been required. What has not been explicitly required is a specific authentication method. Most organizations have satisfied this requirement with username and password alone.

The proposed rule adds explicit language requiring multi-factor authentication for access to information systems that contain ePHI. MFA requires at least two of three factors: something you know (a password), something you have (a device or token), or something you are (biometrics). A password alone no longer satisfies the proposed requirement.

For Greater Sacramento medical practices, this touches every system where staff access patient records. The EHR. The practice management platform. Microsoft 365 or Google Workspace if patient information flows through email. Remote access tools used by providers working from home or across clinic locations. Billing platforms. Patient portals on the administrative side. Each of these represents an authentication point that the proposed rule would reach.

Risk analysis has been a required element of the HIPAA Security Rule since it took effect in 2005. The requirement has not changed. What the proposed rule would change is the level of specificity around what the risk analysis must contain and how frequently it must be performed.

Under the proposal, covered entities would be required to conduct a security risk analysis at least once every 12 months, review and update it whenever environmental or operational changes occur, document the analysis in writing with specific required elements, and have it reviewed and approved by a senior member of leadership. The required elements would include an inventory of all technology assets that interact with ePHI, identification of all threat actors and threat events, assessment of likelihood and impact for each identified risk, and a prioritized remediation plan.

For organizations that have never completed a formal SRA, or that completed one years ago and have not revisited it, the proposed rule creates a clear and auditable standard against which OCR would measure compliance. OCR settlements over the past several years have consistently cited inadequate or absent risk analysis as a primary finding. The proposed rule makes that finding easier to arrive at and harder to dispute.

Two of the most operationally demanding proposed requirements are the technology asset inventory and the business associate verification obligation. Neither exists in specific form under the current rule, though both are logically implied by the general obligation to protect ePHI.

The proposed asset inventory requirement would require covered entities to identify and document every hardware device, software application, and network component that creates, receives, maintains, or transmits ePHI. This is a more rigorous version of the asset awareness that a risk analysis requires implicitly. For practices that have grown organically, added software over time without documentation, or have staff using personal devices for work, building this inventory reveals exposures that were invisible.

The business associate verification requirement would require covered entities to obtain written confirmation that their business associates have implemented the Security Rule requirements. A signed BAA would not satisfy this obligation. You would need actual evidence of controls. For practices with dozens of vendors touching patient data, building a vendor security management program is a material operational undertaking.