The HIPAA Security Rule, in Plain English
What the Security Rule actually covers, how its three safeguard categories translate to real controls, and what the proposed 2025 overhaul changes for business associates.
A clinical workflow startup I know signed its first Business Associate Agreement with a hospital system last year. The ink wasn't dry before the hospital's security team sent over a questionnaire — a long one — asking which HIPAA Security Rule safeguards they had in place. The startup's response was essentially: "We're compliant with HIPAA." The hospital's security team asked for specifics. Blank stares. The deal stalled for two months while the vendor figured out what that phrase was supposed to mean.
The Security Rule isn't complicated at its core. It's a set of standards for protecting electronic health data. But between the jargon, the required-versus-addressable distinction that's confused organizations for two decades, and a major proposed update that has been in regulatory limbo since early 2025, a lot of teams never get past vague assurances to the actual controls the rule requires.
What the Security Rule actually covers
The HIPAA Security Rule is codified at 45 CFR Part 164, Subparts A and C. It governs electronic protected health information — ePHI — meaning health information that identifies (or could identify) an individual and is created, received, maintained, or transmitted electronically.
That last word matters. The Security Rule is strictly about electronic records. Paper documents fall under HIPAA's Privacy Rule. So a faxed referral is not the Security Rule's problem. The EHR system that generated it is.
What qualifies as ePHI has to be read broadly: structured EHR data, yes, but also email containing patient details, a spreadsheet tracking appointments, a backup tape holding claims records, and cloud storage with scanned documents. If it identifies a patient and exists electronically, the Security Rule applies.
Who it applies to
The rule binds two categories of organization.
Covered entities are the primary healthcare players: health plans, healthcare clearinghouses, and most healthcare providers. Hospitals, physician practices, and health insurers are the obvious examples.
Business associates are the vendors and service providers that handle ePHI on a covered entity's behalf. Cloud storage providers, billing companies, EHR hosts, analytics platforms, clinical communication tools — if your product or service involves touching ePHI while performing work for a covered entity, you are a business associate and the Security Rule applies to you directly, not just through contractual pass-through.
The formal relationship between a covered entity and a business associate is documented in a Business Associate Agreement. If you want to understand how a BAA differs from a GDPR DPA (they're genuinely different documents that solve different problems), I broke it down in the DPA vs BAA breakdown.
The three safeguard categories
HHS organizes the Security Rule's requirements into three groups. Understanding the structure makes the rule much easier to navigate.
Administrative safeguards
Administrative safeguards are the policies and processes that govern your security program. The most consequential requirement here is the Security Management Process: you must conduct an ongoing risk analysis, identify vulnerabilities to ePHI, and run a formal risk management program to address what you find.
Access management also lives here — who gets access to ePHI, how that access is approved, and how it gets removed when someone leaves. Workforce training and incident response procedures round out the category.
These look like paperwork exercises. They're not. In enforcement actions, a missing or inadequate risk analysis is one of the most common findings OCR identifies. The risk analysis is the foundation the rest of the rule stands on. Organizations that treat it as a checkbox to complete once and file away tend to have the most problems when something goes wrong.
Physical safeguards
Physical safeguards cover the physical access controls around systems that store or process ePHI: facility access controls, workstation use policies, and device and media controls for how equipment is handled when it moves or gets decommissioned.
For cloud-native vendors whose servers live in AWS or GCP, the data center physical safeguards largely get handled by the cloud provider. But you still need to document that, and you need workstation and device policies covering your own staff. A laptop policy isn't glamorous, but it's part of the rule.
Technical safeguards
Technical safeguards are the technology controls: access control (unique user IDs, automatic logoff, emergency access procedures), audit controls covering who accessed what and when, integrity controls to detect unauthorized alteration of ePHI, and transmission security — encrypting ePHI in transit.
Access control under HIPAA also means implementing the minimum necessary principle: staff should have access only to the ePHI they need to do their job. Least privilege is the underlying concept, and it's as relevant here as it is in any other security framework.
The encryption requirement on data in transit comes up constantly in practice. The current rule technically classifies encryption as "addressable" rather than "required" for data at rest, but any organization transmitting ePHI unencrypted is taking a risk that OCR has pursued aggressively in enforcement.
Required vs. addressable — the part that confuses everyone
Inside each safeguard category, individual implementation specifications are tagged as either required or addressable. Required means you must implement it. Addressable means you must assess whether it's reasonable and appropriate for your organization's risk environment, and either implement it or document why an equivalent alternative suffices.
In theory, this flexibility makes sense: a small rural practice and a large health system have genuinely different threat landscapes. In practice, the addressable designation led two decades of organizations to treat certain controls as optional when they were never meant to be. Encryption of ePHI at rest is the clearest example: technically addressable, universally expected, and the absence of a documented justification in an enforcement investigation is a serious problem.
My read on this: treat "addressable" as "document your reasoning carefully and implement unless you have a genuinely compelling reason not to," not as "skip if inconvenient."
What the 2025 proposed update would change
In December 2024, HHS's Office for Civil Rights published the most significant proposed overhaul of the Security Rule in its history. The NPRM would make several changes that matter:
- Eliminate the required/addressable distinction entirely, making all implementation specifications mandatory
- Require encryption of ePHI at rest and in transit as a hard requirement, not an addressable specification
- Mandate multi-factor authentication across the board — which I covered in detail in MFA, 2FA, and why your auditor keeps asking about it
- Require biannual vulnerability scans and annual penetration testing
- Mandate a technology asset inventory and a network map, both updated at least annually
- Require business associates to provide written certifications to covered entities confirming their technical safeguards are in place, once every 12 months
The public comment period closed in March 2025, and OCR received roughly 4,700 comments. As of mid-2026, no final rule has been published. OCR had targeted spring 2026 for finalization, but that window passed. The current Security Rule remains in effect, and the proposed requirements could still be finalized, revised, or withdrawn.
Where compliance actually breaks down
The Security Rule isn't obscure. Most organizations in healthcare-adjacent spaces know what the controls are. The failures tend to cluster in a few predictable spots:
- Risk analysis done once and never revisited. The rule requires an ongoing process. An analysis completed three years ago for an architecture you've since replaced is not compliance. It's a document.
- Audit logs nobody reviews. Logging is a technical safeguard requirement. Logs that sit unexamined don't detect breaches. Multiple enforcement cases have involved organizations that had audit logging turned on but no process for reviewing what the logs showed.
- BAA gaps at subcontractor level. A business associate that uses subcontractors to process ePHI without sub-BAAs in place creates a compliance gap that OCR has followed up on. A chain of BAAs has to run all the way down.
- Physical safeguards treated as the cloud provider's problem. AWS handles the data center. AWS doesn't handle your employees' laptops, your office workstations, or what happens to a decommissioned hard drive with ePHI on it.
Where to start if you're a vendor with a BAA
If you're a SaaS company that has signed (or is about to sign) a BAA and needs to get serious about the Security Rule: start with the risk analysis. Not a policy template, not a compliance platform — an actual inventory of where ePHI lives in your systems, what could go wrong, and how likely each scenario is. Everything else in the rule flows from that.
From there, access controls and MFA are the fastest wins. Then logging. Then confirmed encryption at rest for any ePHI you store. Work through those four and you'll have a real answer to a hospital's security questionnaire, not a vague assurance.
The frameworks hub has context on how HIPAA sits alongside SOC 2, NIST CSF, and other frameworks that healthcare-adjacent vendors often pursue in parallel. The controls overlap more than most people expect, and if you're already on a SOC 2 path, you're probably closer to HIPAA's technical requirements than you think.