New HIPAA Security Changes Are Likely Coming: What Medical Practices Should Prepare for Now

HHS proposed a major update to the HIPAA Security Rule in December 2024. As of July 2026, it is still not final. But the direction is clear enough that healthcare practices should be paying attention now, not later.

We work with medical groups across Colorado, from single-provider offices to multi-site operations. Most of them are asking the same question: what does this actually mean for us?

Here is what we know so far, and what we think smaller practices should be doing about it.

What is changing

The proposed update would make the Security Rule more specific. For years, HIPAA gave covered entities room to interpret "reasonable and appropriate" on their own terms. The new language narrows that room considerably.

The proposal includes requirements that a lot of smaller practices have put off, sometimes for years. Not because they did not care, but because the cost, complexity, or urgency never quite forced the issue.

Where most practices have gaps

In our experience, these are the areas where smaller organizations tend to be furthest behind:

• Single-factor logins for EHR systems and email
• Encryption that is incomplete or inconsistent across devices
• Risk assessments that are outdated, generic, or hard to defend under scrutiny
• Backup plans that exist on paper but have never been tested
• No formal network map or technology inventory
• Limited vulnerability scanning and no penetration testing
• Security policies that have not been updated or shared with staff in years

None of this is unusual. But the proposed rule would put most of these squarely in the "required" column.

What the proposed rule would require

Based on the HHS fact sheet, the proposed changes point toward specific requirements for regulated entities:

• Multi-factor authentication for access to ePHI (with limited exceptions)
• Encryption of ePHI at rest and in transit
• A documented technology asset inventory and network map
• A written risk analysis that goes beyond checkbox compliance
• Vulnerability scanning at least every six months
• Penetration testing at least once every 12 months
• Annual compliance audits
• Written incident response procedures
• The ability to restore critical systems and data within 72 hours
• Network segmentation

For a practice with 200 users or fewer, this list changes the budget conversation. These are not minor items. They affect how systems are accessed, how vendors are managed, how backups are validated, and how quickly you can recover from an outage.

Why it makes sense to start now

None of this is mandated today. But the direction is clear enough to act on.

If a practice waits until the final rule drops, it may end up trying to do several hard things at once: upgrading security infrastructure, reworking access controls, reviewing vendor relationships, training staff, and budgeting for projects that were never planned. That is when things get expensive and disruptive.

A steady, planned approach gives you time to figure out what is missing, phase in changes, and keep the impact on providers and staff manageable.

Practical starting points

If you are a physician, administrator, or practice manager, these are the areas we would look at first:

1. Check where multi-factor authentication is still missing. EHR access, email, remote desktop, and any cloud application that touches patient data.
2. Verify encryption is consistently in place for stored data and transmitted data, including laptops, portable drives, and email.
3. Update or perform a real risk analysis (not a paperwork exercise, but one that identifies actual gaps in how your organization protects ePHI).
4. Build a current inventory of systems, devices, vendors, and data flows. You cannot protect what you have not documented.
5. Test your backups and ask whether your recovery expectations are realistic. The proposed 72-hour restore window is a useful benchmark.
6. Confirm vulnerability scanning, penetration testing, and incident response planning are being handled on a schedule, not only after something goes wrong.
7. Evaluate your IT support model. Is it built for compliance and resilience, or just for fixing tickets when something breaks?

That last question matters more than most people expect. The proposed rule assumes a level of ongoing security management that goes well beyond break-fix IT.

What a real risk analysis actually involves

The proposed rule calls for a written risk analysis that goes beyond checkbox compliance. In practice, that means more than filling out a questionnaire or running a vulnerability scan and calling it done.

A thorough risk analysis looks at administrative controls, technical infrastructure, and physical security together. That includes reviewing who has access to what, how data moves between systems, whether policies match actual behavior, and whether the physical environment protects the hardware and media where ePHI lives.

We do physical walkthroughs as part of every assessment. You would be surprised how often we find server rooms with unlocked doors, workstations with patient data visible in common areas, or backup drives sitting on a desk with no encryption. Those are the kinds of findings that matter in an audit, and they do not show up in a remote scan.

The deliverable should be something your practice can actually use and defend: a documented inventory of risks, a clear picture of what is and is not in place, and a realistic plan for closing the gaps. If your current risk analysis is a PDF that has been sitting in a drawer since 2022, it is probably time to revisit it.

What the 72-hour restore requirement means in practice

One of the proposed requirements that catches people off guard is the expectation to restore critical systems and data within 72 hours of an incident. For a 200-person hospital system with a dedicated IT department, that is a stretch goal. For a 40-person practice with one IT contact, it can feel impossible.

The reality is that meeting a 72-hour window depends on decisions you make now, not during the crisis. It means having tested backups (not just backups that exist, but ones you have actually restored and verified). It means knowing which systems are critical and in what order they need to come back online. And it means having a recovery plan that your team has seen before the day they need it.

Most of the practices we work with across Colorado have backups in place but have never tested a full restore. That gap between "we have backups" and "we can actually recover" is exactly what the proposed rule is designed to close.

Colorado practices and what we are seeing locally

Colorado has a high concentration of independent and small-group medical practices, especially along the Front Range. Many of these organizations are large enough to be regulated but small enough that dedicated IT security staff is not realistic.

What we see consistently is that the practices furthest ahead on compliance are the ones that started treating security as an ongoing operational concern rather than a one-time project. They budget for it annually, they review their posture regularly, and they have a relationship with an IT partner who understands healthcare.

If you are a Colorado practice trying to figure out where you stand relative to the proposed changes, a structured risk assessment is the most practical place to start. It gives you a clear baseline and a prioritized list of what to address first.