TL;DR: The proposed 2026 HIPAA Security Rule update would eliminate the “addressable” safeguard category and make multi-factor authentication, encryption, network segmentation, and annual risk assessments mandatory for every covered entity and business associate. INVITE Networks builds HIPAA-aligned infrastructure, from compliant cloud architectures to compliance reporting mapped across HIPAA, SOC 2, and CMMC, so IT teams don’t have to interpret the rule from scratch. This guide is for IT Directors, compliance leads, and security leaders at healthcare and healthcare-adjacent organizations who need to know what’s changing and what to do before the rule is finalized. What is changing in the 2026 HIPAA Security Rule update? The U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR) has proposed the first major overhaul of the HIPAA Security Rule since 2013. The Notice of Proposed Rulemaking would eliminate the two-decade-old distinction between “required” and “addressable” safeguards and replace it with a single, more prescriptive standard, along with new mandatory technical controls, audit requirements, and incident response timelines. The rule is not final. OMB’s Unified Agenda now targets July 2027 for final action, pushed back from an earlier spring 2026 target, and the proposal is facing pushback during the public comment process. Until it is finalized, the current Security Rule (with its required and addressable categories) remains in force. That said, IT leaders at healthcare and healthcare-adjacent organizations should not treat the delay as a reason to wait. Implementation timelines tend to compress once a federal rule like this is finalized, and the controls being proposed, multi-factor authentication, encryption, and documented risk analysis, are the same controls auditors and cyber insurers are already asking about today. The proposed rule applies broadly. It covers health plans, health care clearinghouses, and most health care providers directly, along with their business associates: the managed service providers, cloud hosting companies, billing vendors, and software platforms that create, receive, maintain, or transmit electronic protected health information (ePHI) on a covered entity’s behalf. If your organization has a signed Business Associate Agreement (BAA) with a healthcare client, or your own IT vendor has one with you, this rule affects your compliance obligations directly, not just the healthcare organization’s. Which HIPAA safeguards are becoming mandatory instead of addressable? Under the proposed rule, safeguards that were previously “addressable,” meaning a covered entity could implement a reasonable alternative or document why a control wasn’t applicable, become required with no exception path. This directly affects the controls an IT team is responsible for configuring and maintaining day to day. Safeguard Current Security Rule Proposed 2026 Rule Multi-factor authentication Addressable Mandatory on all systems accessing ePHI Encryption of ePHI Addressable Mandatory, at rest and in transit Network segmentation and mapping Not explicitly required Mandatory, documented network map Vulnerability scanning Addressable / discretionary Mandatory, on a regular cadence Penetration testing Not explicitly required Mandatory, at least annually Asset inventory Addressable Mandatory, kept current What does the new 72-hour incident response requirement mean for your team? The proposed rule would require covered entities and business associates to restore critical systems and data within 72 hours of a security incident, and to document, implement, and annually test a formal incident response plan. That is a specific, measurable recovery target, not a general expectation to “respond promptly.” Operationally, a 72-hour restoration standard puts pressure on backup architecture, recovery runbooks, and the process for determining whether an incident is HIPAA-reportable. Organizations that rely on manual, undocumented recovery steps, or that have never run a tabletop exercise against their own incident response plan, are the ones most exposed once this requirement becomes enforceable. Annual testing also means the plan has to reflect the environment as it exists today, not the environment as it existed when the plan was first written. Breach determination is its own workflow, separate from restoration. A security incident and a HIPAA-reportable breach are not automatically the same thing, and the proposed rule’s accelerated timelines put more pressure on getting that determination right quickly. IT and compliance teams need a documented process for pulling in legal counsel, assessing the probability that ePHI was compromised, and notifying affected individuals and HHS within the required windows, running in parallel with, not after, system restoration. How often will HIPAA compliance need to be reviewed under the proposed rule? The proposed rule would require a formal, documented security risk assessment at least annually, along with periodic evaluation of whether existing security measures still meet current Security Rule requirements. Compliance shifts from a point-in-time audit to a continuous program. For IT teams, this means the annual risk assessment can no longer be treated as a compliance checkbox completed once a year and set aside. Asset inventories, network maps, and vulnerability scan results all need to stay current between assessments, because the assessment itself is only as accurate as the documentation behind it. Organizations that already run continuous vulnerability management and maintain a living asset inventory will have far less to build than those trying to reconstruct this documentation from scratch during audit season. This is also where the proposed rule’s annual penetration testing requirement connects back to the risk assessment. A penetration test performed once and filed away doesn’t hold up under a compliance model built around continuous review. Testing needs to feed back into the risk assessment, and any findings need a documented remediation timeline that an auditor can follow, not just a report showing the test happened. NIST SP 800-66 Revision 2 is the closest thing to a regulator-aligned implementation playbook for this process, and it’s a useful reference regardless of when the final rule lands. Does HIPAA compliance overlap with SOC 2 or CMMC requirements? Yes. HIPAA, SOC 2, and CMMC share several control families, including access control, risk assessment, encryption, and incident response, so an organization already working toward SOC 2 or CMMC compliance has a real head start on the proposed HIPAA controls. INVITE has covered both frameworks in detail: see SOC 2 Compliance for Mid-Market Companies and CMMC Compliance Consulting. The overlap has limits. HIPAA’s breach notification timelines, its definition of a business associate, and its ePHI-specific technical requirements do not map one-to-one onto SOC 2’s trust services criteria or CMMC’s controlled unclassified information scope. An organization subject to more than one framework still needs a compliance program that accounts for each framework’s specific triggers, not just the shared technical controls. How INVITE builds HIPAA-aligned IT infrastructure for healthcare and regulated clients INVITE Networks designs and manages infrastructure for clients that handle ePHI and other regulated data, without treating compliance as a separate project bolted onto the network. For one healthcare client, INVITE designed and deployed a colocation footprint at Novva Data Center, migrating systems into a facility with tier-appropriate redundancy and HIPAA-aligned physical controls. For clients running workloads in the cloud, INVITE deploys HIPAA-compliant AWS architectures and maintains ongoing configuration management, so audit findings don’t accumulate between review cycles. INVITE also integrates platforms like Keeper and Five9 into a broader compliance posture, using their built-in reporting modules to generate the audit trails and access logs that satisfy HIPAA, SOC 2, PCI DSS, and CMMC requirements at once, rather than maintaining separate evidence for each framework. This is the same discovery-first approach INVITE applies across every engagement: understand what data lives where, on what systems, before recommending a control. For a HIPAA-regulated environment, that means mapping ePHI flows across on-premises systems, cloud workloads, and any third-party platforms before proposing the network segmentation, encryption, and monitoring changes the proposed rule would require. It’s a slower first step than dropping in a generic security stack, and it’s the reason the resulting compliance posture actually holds up under audit. Frequently Asked Questions What is a HIPAA Security Risk Analysis? A HIPAA Security Risk Analysis is a formal, documented process that identifies where an organization stores, processes, or transmits electronic protected health information (ePHI), evaluates the threats and vulnerabilities to that data, and assesses whether current safeguards are sufficient. It differs from a general IT security review because it must be mapped directly to specific Security Rule citations. Is HIPAA compliance mandatory for IT vendors and managed service providers? Any vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity, including most managed service providers, qualifies as a business associate under HIPAA and is directly liable for compliance. This requires a signed Business Associate Agreement (BAA) and independently subjects the vendor to HIPAA’s security and breach notification requirements. What counts as a business associate under HIPAA? A business associate is any person or organization, other than a member of a covered entity’s own workforce, that performs functions or services involving ePHI on the covered entity’s behalf. This commonly includes IT service providers, cloud hosting providers, billing companies, and software vendors with access to patient data. What happens if the final HIPAA Security Rule is delayed again? If OCR delays the final rule beyond its current July 2027 target, the existing Security Rule, including the required and addressable safeguard distinction, remains fully enforceable in the meantime. A further delay would not reduce current compliance obligations, and organizations that wait for finalization before addressing known gaps risk having less time to implement once the rule does take effect. Do smaller healthcare organizations need the same controls as large hospital systems? The Security Rule’s safeguards apply based on whether an organization handles ePHI, not its size, though HHS has historically allowed some flexibility in how a smaller organization implements a given control. Under the proposed rule’s shift away from addressable safeguards, that flexibility narrows considerably, so organizations of any size should expect to implement the same core technical controls. Ready to see where your organization stands against the proposed rule? Schedule a HIPAA compliance gap assessment with an INVITE security engineer.
