HIPAA's First Security Rule Overhaul Since 2003: What Every Therapist Needs to Know
The HIPAA Security Rule hasn't been updated since 2003 — before iPhones, cloud EHRs, or ransomware-as-a-service. HHS's January 2025 proposed overhaul would mandate MFA, encryption, and annual security audits across every therapy practice. Here's what's proposed and what to do now.
A Rule Written Before the Cloud Existed
The HIPAA Security Rule was finalized on February 20, 2003. At that point in history, the Apple iPod was four months old. Facebook didn't exist. The iPhone was still four years away. And most therapy practices kept their clinical notes in paper file folders — with a lock on the cabinet and a shredder in the corner.
That is the vintage of the regulation that still governs how therapy practices protect electronic patient health information (ePHI) today. HHS has issued subsequent guidance documents and enforcement actions over the years, but the underlying Security Rule has never been substantively amended. Cloud-based EHRs, HIPAA-compliant messaging apps for patient communication, remote work, third-party billing services that touch ePHI — none of these existed when the rule was written. The rule's threat model was built for a world of on-premises file servers and floppy disks.
On January 6, 2025, HHS published a Notice of Proposed Rulemaking in the Federal Register (90 FR 898) proposing the first significant overhaul of the HIPAA Security Rule in more than two decades. The public comment period closed March 7, 2025. The proposed rule has not been finalized — the Office of Management and Budget currently targets July 2027 for final action — but the direction is clear, and the gap between what the current rule requires and what modern cybersecurity demands is no longer defensible.
For therapy practices of every size, this is the regulatory change to understand before the final rule lands.
What 2024's Breach Crisis Has to Do With Your Practice
The proposed overhaul didn't emerge from a policy vacuum. It was triggered in large part by the state of healthcare cybersecurity, which by 2024 had reached a genuine crisis point.
According to the HHS Office for Civil Rights, 2024 set an all-time record for healthcare data breaches: 725 large breaches reported to OCR, affecting approximately 289 million individuals — roughly 87% of the U.S. population (HIPAA Journal, 2024 Healthcare Data Breach Report). The single largest incident was the Change Healthcare ransomware attack in February 2024, which exposed the records of an estimated 192.7 million people — the largest health data breach in U.S. history by a factor of two.
Hacking and IT incidents accounted for 81.2% of all reported healthcare breaches in 2024. Healthcare remained the most expensive industry for data breaches for the 14th consecutive year, with an average cost of $7.42 million per incident (IBM Cost of Data Breach Report, 2024) — nearly double the cross-industry average.
Most of these incidents targeted large hospital systems and clearinghouses, not private practice therapy offices. But the enforcement logic is direct: protected health information held by a solo therapist carries the same legal weight as PHI in a hospital system. A small practice that stores session notes in a cloud EHR, schedules through a third-party platform, and communicates with clients via encrypted messaging is operating a digital ePHI environment — and one that the 2003 Security Rule was not built to govern effectively. The 2025 proposed rule is HHS's attempt to close that gap before the next large-scale event happens.
The Six Biggest Proposed Changes
The proposed Security Rule overhaul addresses six major areas. These are proposed changes — not law yet — but they define where compliance requirements are heading and what practices should be building toward:
| Proposed Requirement | What It Means in Practice | Current Status |
|---|---|---|
| Mandatory multi-factor authentication | Required for all workforce access to systems that create, receive, maintain, or transmit ePHI | Currently "addressable" — many practices opt out |
| Mandatory encryption at rest and in transit | All ePHI must be encrypted wherever stored and during transmission; no documented alternatives permitted | Currently "addressable" — documented alternatives allowed |
| Annual mandatory risk analysis | Formal written security risk analysis of all ePHI systems, repeated every calendar year | Required in theory; annual frequency not explicitly mandated |
| Technology asset inventory | Written inventory of all hardware, software, and services that store, transmit, or touch ePHI | No current explicit requirement for a formal inventory |
| Incident response plan with annual testing | Documented breach response procedure with required annual tabletop exercise testing | Broadly required but testing not mandated or scheduled |
| Vulnerability scanning and penetration testing | Annual vulnerability scans of all ePHI-touching systems; penetration testing at least every two years | No current explicit requirement |
Two notes worth knowing before the alarm bells go off. First, most major HIPAA-compliant EHR platforms — SimplePractice, TherapyNotes, Jane, Luminare Health's products — already implement encryption at rest and in transit as a standard feature. If your EHR has a signed BAA and has been HIPAA-certified by a credible auditor, the encryption requirement may be met at the vendor level. Confirm this in your platform's security documentation. Second, MFA is typically a five-minute account settings task, not a technical implementation project. The heavier lift is documentation: formal written risk analyses, asset inventories, and tested incident response plans require time and intentionality, not just a software update.
The End of 'Addressable' Safeguards — The Biggest Structural Change
The most consequential structural change in the proposed rule is the one receiving the least attention in general coverage: the elimination of the "addressable" designation for security implementation specifications.
The current HIPAA Security Rule divides its implementation specifications into two categories. "Required" specifications must be implemented exactly as described, with no flexibility. "Addressable" specifications allow a covered entity to either implement the specification as written, implement a reasonable equivalent alternative, or document in writing why neither option is appropriate given their specific circumstances and risk profile.
In practice, the "addressable" flexibility gave small practices significant room — and sometimes functioned as a formal escape hatch. Encryption was addressable. Multi-factor authentication was addressable. A solo practice with a documented risk analysis concluding that a given alternative was sufficient could, in theory, forgo these controls without being out of compliance on paper.
The proposed rule would eliminate this flexibility entirely. All implementation specifications would become "required," with only narrow documented exceptions. From HHS's perspective, the distinction made sense in 2003 when implementing enterprise-grade encryption would have required specialized software and expertise that small practices genuinely could not access. In 2026, encryption is a commodity feature in virtually every enterprise software product and MFA is available on every major platform at no additional cost. The "addressable" flexibility has aged from a necessary accommodation into an outdated permission to skip basic security controls.
For practices that have relied on the flexibility of "addressable" safeguards — either by documenting genuine alternatives or by de facto not implementing them — this is the change that forces a real audit. The "we documented an alternative" escape hatch goes away in the final rule.
What APA Said About the Small Practice Impact
The American Psychological Association engaged formally in the rulemaking process. On March 7, 2025 — the final day of the comment period — APA CEO Arthur C. Evans Jr., PhD, submitted formal comments on behalf of APA Services to the HHS Office for Civil Rights.
The APA's core concern: the proposed rule as written applies uniformly to practices of every size, with no meaningful accommodation for the solo practice reality. A hospital system with a dedicated cybersecurity team, a CISO, and a seven-figure security budget can implement annual penetration testing and formal written risk analyses without existential strain. A solo therapist with a laptop, a cloud EHR subscription, and a part-time billing assistant faces a fundamentally different situation — and the proposed rule as drafted makes no distinction between the two.
APA specifically requested that HHS either exempt solo and small practices from certain proposed requirements, or implement extended compliance timelines so smaller providers have adequate time to adapt. Additional APA requests included maintaining flexibility for requirements without a one-size-fits-all implementation, providing financial support for small providers who weren't eligible for earlier federal health IT funding under HITECH, and developing guidance and resources specifically designed for small practice realities — not scaled-down versions of hospital compliance frameworks.
The outcome of these advocacy efforts won't be clear until HHS issues the final rule. But the APA's engagement confirms what is already evident from the rule's text: the proposed requirements as written don't scale naturally to one-person practices, and the professional associations are actively working to address that. Watch for potential size-tiering, phased implementation timelines, or adjusted requirements for small practices in the final rule — these are among the most likely modifications if HHS incorporated the volume of small-provider comment feedback received.
Where the Rule Stands — and What the Timeline Actually Looks Like
The proposed HIPAA Security Rule overhaul remains in the rulemaking process. Here is the current timeline:
| Milestone | Date / Status |
|---|---|
| NPRM published in Federal Register (90 FR 898) | January 6, 2025 |
| Public comment period closed | March 7, 2025 |
| OMB target for final rule publication | July 2027 |
| Estimated compliance deadline (240 days after final rule) | Early 2028 at earliest |
The OMB timeline is not legally binding — it could shift earlier or later depending on regulatory priorities, administration policy choices, and any legal challenges to the final rule. The Trump administration has generally moved toward regulatory reduction across healthcare, creating genuine uncertainty about whether the rule will publish in its proposed form, in a modified form, or be further delayed. It is plausible that the final rule includes significantly softened requirements, especially for small practices, given the volume of comment feedback.
Compliance is not required today, and won't be required for at least 18 months after a final rule publishes. A practice that waits until 2027 to begin thinking about this hasn't missed anything. What it has missed is the opportunity to implement changes incrementally — enabling MFA now takes five minutes; doing it as a compliance scramble alongside penetration testing paperwork in late 2027 takes much longer.
Six Steps Every Therapy Practice Should Take Now
The proposed changes haven't been finalized. That is reason not to panic — it is not reason to ignore the trajectory. Here are six steps that make sense now, regardless of how the final rule shapes up:
Enable MFA on every system that touches ePHI. Your EHR, your email, your scheduling software, your cloud storage. Most platforms support authenticator apps (Google Authenticator, Authy) or hardware security keys. Credential theft is the most common single entry point for small practice breaches, and MFA blocks the majority of those attacks. If your EHR supports it and you haven't enabled it, this is the highest-leverage five-minute task available.
Confirm your EHR handles encryption at rest and in transit. Major HIPAA-compliant EHRs encrypt ePHI at rest and in transit as part of their standard offering. Verify this in your platform's security documentation or BAA — look for specifics (AES-256 at rest, TLS 1.2 or higher in transit), not just "bank-level security" marketing language. If you can't find it, contact your EHR's support team and ask directly.
Conduct a technology audit. List every system, platform, and service that stores, receives, or transmits PHI: your EHR, telehealth platform, scheduling software, billing service, patient intake forms, email, cloud storage, and any client-facing contact forms on your website. This is the foundation for the asset inventory the proposed rule would require — and the audit itself typically reveals one or two systems that practices hadn't consciously considered part of their ePHI environment.
Review all Business Associate Agreements. Every vendor that touches ePHI must have a current, signed BAA. Run through your technology audit list and confirm BAAs are in place and up to date. Any vendor that doesn't offer a BAA is a current HIPAA compliance gap — not a future one.
Start documenting your security practices. The proposed rule places significant weight on written documentation: written risk analyses, written policies, written incident response plans. Begin the habit now by writing down what security measures you currently have in place — which EHR settings you've enabled, how you respond if you suspect a breach, which vendors hold ePHI, and how you've decided to handle each. Even an informal written record is the foundation for the formal documentation the rule will require.
Check whether your professional liability coverage extends to cyber incidents. Many therapist malpractice policies are silent on cybersecurity events. Standalone cyber insurance for solo practices typically runs $300–$600 per year and covers breach response costs, client notification expenses, and liability from a ransomware or credential-theft incident. Given the documented trajectory of healthcare-targeted attacks, this is worth evaluating now, independently of any regulatory requirement.
Your Website Is Part of Your ePHI Environment
One dimension of the proposed Security Rule that applies specifically to how practices use their websites: any online system that collects protected health information — an intake form that asks about presenting concerns, a scheduling tool that captures appointment purpose, a contact form a client uses to describe their situation — is part of your ePHI environment and subject to Security Rule requirements.
A HIPAA-compliant intake form requires a signed BAA with the form platform. An embedded scheduling system that collects health information must handle that data with appropriate encryption. A therapy website built on a generic website platform that stores form submissions in a non-HIPAA-configured database creates both a BAA gap and a potential breach surface — the kind the proposed rule's asset inventory requirement would force practices to document and address explicitly.
The website-specific dimensions of HIPAA compliance are covered in detail in our guide to HIPAA-compliant therapy websites. The proposed Security Rule doesn't change the fundamental website requirements — BAA with the platform, encrypted transmission, no PHI stored in non-compliant systems — but would tighten how practices document and audit the systems their sites depend on.
The pattern is consistent across the three major compliance frameworks affecting therapy websites: FTC marketing compliance, ADA accessibility compliance, and HIPAA data security compliance all increasingly require that the web infrastructure hosting a practice be purpose-built for healthcare — not adapted from a generic website builder with workarounds bolted on. WebsiteTherapy sites are built with HIPAA-aware architecture from the foundation: encrypted data handling, BAA-eligible infrastructure, and a feature set designed for the compliance requirements therapy practices actually face. See how it works.