For twenty years, the HIPAA Security Rule has run on an honor system. “Addressable” specifications let organizations document their way around encryption and MFA. “Periodic” risk analysis meant whenever you got around to it. And when OCR came knocking after a breach, the defense was a binder: policies, attestations, and a risk assessment from eighteen months ago.
That era is ending. The HIPAA Security Rule update proposed by HHS in January 2025, the first major overhaul since 2013, removes the word “addressable” from the vocabulary of healthcare security. Every safeguard becomes required. Every requirement demands documented, dated evidence. And final action is coming: OCR has signaled the rule is moving forward, with compliance windows measured in months, not years, once it lands.
The punchline, and it’s the one compliance teams haven’t internalized yet, is that the new rule doesn’t ask whether you have controls. It asks whether you can prove they were operating: continuously, with timestamps, for every system that touches ePHI.
A policy document can’t answer that question. Only evidence can.
What’s actually changing
Five proposed mandates stand out for the operational burden they create.
- Annual mandatory risk analysis. The vague “periodic” language is gone. Covered entities and business associates must conduct a risk analysis at least annually, and after any major change, with documented results, evidence, and control decisions every time. The risk assessment you did for your last audit cycle no longer carries you.
- Tightened business associate oversight. The proposal requires current BAAs with every PHI-handling vendor, annual written verification from business associates that safeguards are deployed, and 24-hour notification requirements for critical events. The uncomfortable part: covered entities carry liability exposure when their BAs fail. “We sent them a questionnaire in 2024” is not due diligence anymore.
- MFA becomes mandatory for ePHI access. Multi-factor authentication moves from addressable to required across all systems touching ePHI: EHRs, remote access, email, admin platforms. Not “we have an MFA policy.” MFA operating, everywhere, provably.
- Encryption of ePHI at rest and in transit. Full encryption using current cryptographic standards, with narrow exceptions. The option to document your way out of encrypting is eliminated. If you can’t map where ePHI lives and moves, you can’t demonstrate it’s encrypted.
- Scheduled vulnerability scanning and penetration testing. Automated vulnerability scans at least every six months and annual penetration testing, on defined schedules, with documented results and remediation tracking. Ad hoc scanning when the security team has bandwidth doesn’t satisfy a defined-cadence requirement.
Individually, each of these is manageable. Together, they redefine what a HIPAA compliance program is: not a set of policies reviewed annually, but a continuously operating evidence machine.
The spreadsheet era can’t survive this
Every healthcare security leader we talk to says a version of the same thing: “I’ve bought every security tool on the planet, and I still can’t prove my ePHI systems are operating securely.” Most healthcare compliance programs were built for the old rule. Risk registers live in spreadsheets. Vendor assessments are emailed questionnaires. MFA enforcement is a screenshot taken the week before the audit. Encryption coverage is asserted, not observed. This is why I lovingly call GRC “governance, risk, and conjecture.” Sampled screenshots and self-reported questionnaires produce guesses, not ground truth.
That model fails the new rule structurally, not marginally. Consider the math: annual risk analysis with full documentation, plus reassessment after every major change, plus written verification from every BA, plus continuous proof that MFA and encryption are operating across every ePHI system, plus four-plus scan cycles and a pen test every year, each producing findings that must be tracked to remediation. For a mid-sized covered entity with hundreds of vendors and dozens of ePHI systems, that’s thousands of evidence artifacts a year, each needing to be current when OCR asks.
Point-in-time compliance tells you what your control state was the day someone checked. The new Security Rule effectively demands you know what it is. Those are different capabilities, and no amount of headcount closes the gap with spreadsheets.
Mapping the mandates to a continuous model
So the question for us was never whether healthcare teams need more controls. It’s whether they can prove the ones they have. This is the problem TrustCloud was built for. Here’s how each mandate maps to a continuous, evidence-first approach:
Annual risk analysis → TrustRegister
Continuous, programmatic risk scoring with financial impact quantification, control mapping, and a full audit evidence trail. When the annual analysis comes due, or a major change triggers a reassessment, the documentation already exists. You’re always audit-ready, on demand, instead of reconstructing a year of decisions in a two-week scramble.
BA oversight → TrustLens
AI-native vendor risk assessments replace the questionnaire-chasing cycle. Every BAA is tracked, every PHI-handling vendor is continuously monitored, and the due diligence record is defensible, which matters when the regulation makes their failure your liability.
MFA enforcement → Continuous Control Monitoring
Live signals from identity systems like Okta and Azure AD verify MFA is actually operating, not just documented in a policy. Timestamped proof of enforcement, ready for any OCR inquiry, without anyone taking screenshots.
Encryption everywhere → Asset Inventory + Control Graph
A live map of every ePHI data flow across cloud and on-prem environments, starting with your digital crown jewels, the applications your business can’t survive without. Encryption gaps get flagged in real time, surfaced as they emerge, not discovered at audit or, worse, in a breach investigation.
Scanning and pen testing → TrustOps + Risk Evidence Analysis
Findings from your existing scanning and pen test tools flow in as evidence artifacts, mapped to controls, with remediation timelines tracked. When OCR asks for your scan history, every cycle of results surfaces instantly.
And candidly: TrustCloud isn’t trying to replace your system of record, your ticketing tools, or your workflow engine. We’re the automation layer underneath them, with validated, continuous control evidence feeding the stack you already run. No rip and replace.
The pattern across all five: the regulation demands proof of operation, and proof of operation can’t be manufactured retroactively. It has to be collected continuously, as a byproduct of how your program runs.
Don’t wait for the final rule
The compliance window after finalization is expected to be short, on the order of 180 days after the effective date. Standing up annual risk analysis, continuous MFA verification, full encryption mapping, vendor monitoring, and scheduled testing cadences is not a 180-day project if you’re starting from spreadsheets.
But the more important reason not to wait: everything in this proposal is already the standard OCR expects in enforcement actions today. Risk analysis failures are among the most commonly cited deficiencies in OCR enforcement actions. The proposed rule doesn’t invent new expectations. It codifies the gap between what organizations document and what they can prove.
The healthcare organizations that come through this transition strongest won’t be the ones that read the final rule fastest. They’ll be the ones that stopped treating compliance as an annual documentation exercise and started treating it as a continuous, evidence-backed operating posture, before the rule forced the issue.
The new Security Rule asks one question, five different ways: can you prove it? Make sure your answer doesn’t depend on a binder.
