The HIPAA security rule wants a rewrite

The Director of the HHS Office for Civil Rights has spent July in a state of apparent leisure, or so it seems from the outside. But while the agency appeared to be nodding off during the summer heat, it managed to slip through a surprise access regulation and a set of updates regarding security delays. It's a classic move: wait for the general attention span to dip, then shift the goalposts on how health data must be handled.

The current chatter around a HIPAA Security Rule revamp suggests that the regulator wants to modernise. In the press releases, this is framed as a victory for patient agency and smooth data flow. If you read the actual requirements, however, it's more about who has to file what and how quickly they must do it when things go wrong.

The friction here isn't technical; it's administrative. The new access regulations essentially demand that providers move faster on data requests, yet they provide very little in the way of updated guidance on how to do so without opening a side door for bad actors. We're being asked to open the windows wider while the locks are still broken.

Look at LifeSpan Physician Group. Their appearance on the 2026 breach tracker is an uncomfortable reminder that the "security" part of the Security Rule is often treated as a suggestion rather than a requirement. When a firm ends up on that list, it's rarely because they forgot to file a form. It's because the technical controls were an afterthought.

Then there's the matter of the blood pressure cuffs. Both the FTC and HHS have pointed out that these devices are leaking sensitive health data. This is where the framework fails entirely. The rules focus on the "covered entity" (the clinic or the hospital), but they're remarkably quiet on the hardware that the patient takes home. The data leaks from a cuff, travels through an unencrypted app, and suddenly the provider is the one facing a probe because they allowed the device into their ecosystem.

The strongest objection to a total revamp of the Security Rule is usually based on cost. Industry lobbyists argue that healthcare providers are already stretched thin and that adding another layer of compliance would be ruinous. They claim that "reasonable and appropriate" safeguards are enough.

They're wrong.

Keeping the status quo isn't a cost-saving measure; it's a liability gamble. When you rely on vague terms like "reasonable," you aren't building security; you're building a legal defence for when the breach inevitably happens. A tighter, more specific framework would actually reduce the guesswork for the people tasked with implementing it.

The second-order effect here hits the auditors and the insurers. If the OCR continues to issue surprise regulations without updating the core Security Rule, the audit reports being signed off today are essentially fiction. An auditor can check a box saying a provider meets the current HIPAA standard, but that doesn't mean the provider is protected against the vulnerabilities the FTC is currently flagging in medical IoT devices.

Insurers will eventually notice this gap. When they see a cluster of breaches linked to "standard-compliant" hardware that leaks data like a sieve, they won't lower their premiums based on a SOC 2 report or a HIPAA attestation. They'll raise them because the framework itself is toothless.

The OCR can keep tinkering with access regulations and pretending that a few updates in July constitute a strategy. But until the Security Rule addresses the hardware gap and moves away from "reasonable" as a primary metric, it's just paperwork for the sake of paperwork.

I'll be watching to see if the proposed revamp actually mandates specific encryption standards for third-party peripherals or if it just adds another form for providers to fill out every ninety days. Given the track record, I wouldn't bet on the former.