Skip to main content

HIPAA Security Rule Delayed to 2027. Your Exposure Wasn't.

MnemoShare Security TeamAugust 17, 20268 min readCompliance

HHS moved the HIPAA Security Rule overhaul to its Long-Term Actions agenda this summer, with July 2027 now listed as the target for final action. It had been expected in May 2026.

For anyone who had a 2026 remediation budget tied to that date, the temptation is to slow down.

That would be a mistake, and not for the reason people usually give. This is not a "the rule is coming eventually so prepare now" argument. It is narrower than that. The obligations most organizations think are arriving in 2027 are already in force. The proposed rule would mostly remove your ability to argue about them.

What actually changed?

The rulemaking timeline, and nothing else.

HHS published the Notice of Proposed Rulemaking on January 6, 2025 at 90 FR 800. It would have been the first substantive overhaul of the Security Rule in roughly two decades. The comment period closed in March 2025, a final rule was preliminarily expected in May 2026, and the Fall 2026 Unified Agenda has since moved it to Long-Term Actions with a July 2027 target.

Unified Agenda dates are planning estimates rather than binding deadlines. Placement on Long-Term Actions generally signals the agency does not expect to finalize within twelve months. HHS has not publicly explained the move.

If finalized as proposed, the rule would become effective 60 days after publication with compliance required 180 days after that, roughly 240 days total, and business associate agreements updated within a year. HHS estimated first-year compliance costs across regulated entities at approximately $9 billion.

Separately, and less discussed, HHS's regulatory agenda has indicated an August 2026 target for a final rule implementing changes to the HIPAA Privacy Rule. That one has not moved to Long-Term Actions. Worth watching while everyone's attention is on the Security Rule.

Is encryption required under HIPAA?

Not as a required implementation specification, and this is the most consequential misunderstanding in healthcare security.

Under 45 CFR 164.306(d), every implementation specification in the Security Rule is labeled either Required or Addressable. Encryption appears at 164.312(a)(2)(iv) and 164.312(e)(2)(ii), and in both places it is Addressable.

Most people read "addressable" as "optional." It is not.

Under 164.306(d)(3), when a specification is addressable, a covered entity or business associate must:

  1. Assess whether it is a reasonable and appropriate safeguard in their environment, and
  2. Implement it if it is, or
  3. If it is not reasonable and appropriate, document why, and implement an equivalent alternative measure where the standard still requires protection.

So the actual obligation is: implement encryption, or produce a documented risk-based rationale for why you did not plus a substitute control that does the same job.

An organization that simply skipped encryption without that analysis has not exercised flexibility. It has failed to meet the specification. Addressable is a documentation and analysis duty, not permission to opt out.

That distinction is why the delay changes less than it appears to. The proposed rule would make encryption required and remove the addressable category. But the current rule already demands either the control or a defensible written justification. Very few organizations have the second thing.

What is OCR enforcing right now?

The existing rule, in full, and its recent enforcement has concentrated on fundamentals rather than novel requirements: accurate and thorough risk analysis, appropriate security measures, vendor risk management, workforce training, and response to known vulnerabilities.

Note what is on that list. Risk analysis is Required, not addressable, at 164.308(a)(1)(ii)(A). So is risk management. So is information system activity review, the specification that obliges you to regularly review audit logs, access reports, and security incident tracking.

None of that is waiting on 2027.

Why the delay does not reduce exposure

Three reasons, in order of how quickly they bite.

Your customers are not waiting for HHS. Business associate agreements and vendor security questionnaires already ask for encryption in transit and at rest, multi-factor authentication, and audit logging. A health system's vendor risk team does not care what the Unified Agenda says. The market moved ahead of the regulator, which means the commercial deadline arrived before the regulatory one.

The safe harbor is unchanged and undervalued. Under 45 CFR 164.402, ePHI encrypted to NIST-approved standards with keys kept secure may fall outside breach notification obligations entirely, because the data is unusable to an unauthorized recipient. That is available today. It is arguably a stronger incentive than any penalty in the proposed rule, and it does not depend on the rulemaking finishing.

A delayed rule is not a withdrawn rule. The proposal is on Long-Term Actions, not off the agenda. Organizations that use the extra time are fine. Organizations that read it as cancellation face a 240-day clock whenever it does land, and 240 days is not enough time to encrypt an estate, deploy MFA everywhere, and rebuild vendor agreements.

What happens to a 2026 remediation budget?

This is the question nobody else is answering, and it is the one compliance officers are actually asking this month.

If you built a 2026 line item around a May 2026 final rule, that money is now attached to a deadline that moved eighteen months. Three ways that goes, and only one of them is good.

It gets clawed back. The most common outcome and the worst one. The work still needs doing, the budget is gone, and you will be asking for it again in a harder cycle.

It sits unspent. Slightly better, but unspent security budget in one cycle is the argument finance uses to cut it in the next.

It gets re-pointed at obligations already in force. The only version that leaves you better off. Everything in the section above is already Required or already an addressable duty you likely have not documented. Spending 2026 money on a current-rule risk analysis, on writing down your addressable decisions, and on closing the evidence gap is not speculative work. It is the same work the proposed rule would have forced, minus the deadline pressure.

The framing that tends to survive a budget conversation: this is not preparation for a rule that may finalize in 2027. It is remediation against a rule that has been enforceable since 2005 and is the basis of current OCR enforcement.

What to do with the extra time

The obligations that are already Required, and already enforced, are the same ones the proposed rule would tighten. Working on them now is not speculative.

Make your risk analysis real. It is Required, it is the single most common finding in OCR enforcement, and a stale one is worse than none because it documents that you knew.

Write down your addressable decisions. For every addressable specification you have not implemented as written, there should be a document saying why and what you did instead. If that document does not exist, the specification is not addressed. That is the cheapest gap to close on this list.

Inventory where ePHI leaves. Not where it lives. Where it goes. Every payer, referring provider, lab, billing vendor, and outside counsel is a path, and each one needs an answer to who accessed what.

Read your BAAs as they will be rewritten. If the rule finalizes, agreements get updated within a year of the effective date. Knowing which of your vendors will struggle is useful now.

Where MnemoShare fits, and where it does not

Worth being exact, because compliance is a category where vendors overclaim.

No product makes an organization HIPAA compliant. Compliance is a property of your organization's practices, documentation, and risk decisions, not of any software you buy. Any vendor telling you otherwise is selling you a problem.

What tooling can do is make specific obligations cheaper to satisfy and easier to evidence. For external file exchange specifically, MnemoShare produces a structured, tamper-evident access record for every transfer, exported to storage you control, so the question of who accessed a record after it left your environment is a query rather than a reconstruction. That speaks to the information system activity review specification and to the evidence half of risk analysis. It does not speak to workforce training, physical safeguards, or your policies.

We are a business associate to our healthcare customers, which means the proposed rule would apply to us as well. Our compliance status is published at mnemoshare.com/trust rather than asserted here.

More on the mechanism in SOC 2 Audit Logging for File Transfers and in Shadow AI Is an Egress Path You Have No Record Of.

The short version

The Security Rule overhaul is delayed, not cancelled. The current rule already requires a real risk analysis, real activity review, and either encryption or a written explanation of what you did instead.

If you were counting on 2026 to force the conversation internally, you have lost your deadline but not your exposure. The better question for this quarter is not what the new rule will require. It is whether you could produce the documentation the current one already does.

Request a demo

Sources

compliancehipaasecurity-ruleencryptionrisk-analysisbusiness-associate
HIPAA Security Rule Delayed to 2027. Your Exposure Wasn't. | MnemoShare Blog