HIPAA is often treated as a single monolithic requirement, but it is actually a set of distinct rules, and confusing them leads to real compliance gaps. This article focuses specifically on the Security Rule — what it governs, the three categories of safeguards it requires, and the single most commonly misunderstood term in the entire regulation: "addressable."
The Security Rule vs. the Privacy Rule
The HIPAA Privacy Rule governs how protected health information (PHI) may be used and disclosed in any form — paper records, verbal conversations, electronic systems. The HIPAA Security Rule is narrower and more technical: it governs specifically electronic PHI (ePHI) — how it must be protected wherever it is created, received, maintained, or transmitted electronically.
Why the distinction matters operationally
A clinic mishandling a paper chart is a Privacy Rule issue. A clinic running an unpatched server that stores patient records, or emailing ePHI without encryption, is a Security Rule issue. IT and security teams are almost always responsible for Security Rule compliance specifically — it's the rule that translates directly into technical controls, vendor selection, and system architecture decisions.
The three safeguard categories
The Security Rule organizes its requirements into three categories: Administrative, Physical, and Technical safeguards. All three are required — an organization cannot substitute strong technical controls for missing administrative ones, or vice versa.
| Category | What it covers | Representative requirements |
|---|---|---|
| Administrative | The policies, processes, and workforce practices that govern how ePHI is handled | Risk analysis, workforce security training, formal access management policy, business associate agreements (BAAs) with any vendor that touches ePHI |
| Physical | Protecting the physical spaces and devices where ePHI lives | Facility access controls, workstation security and placement, secure device and media disposal at end of life |
| Technical | The systems-level controls enforced in software and infrastructure | Access control (unique user IDs, role-based permissions), audit controls (logging), integrity controls, transmission security including encryption |
Administrative safeguards are frequently underinvested relative to technical controls, but they're the foundation the rest depends on — a risk analysis is explicitly the required starting point for the entire Security Rule, not an optional planning exercise. Without a documented risk analysis, an organization has no defensible basis for which technical and physical controls it chose (or didn't).
Physical safeguards matter even in a heavily cloud-based environment — a workstation left unlocked in a shared space, or a decommissioned laptop disposed of without wiping its drive, is a physical safeguard failure regardless of where the ePHI itself is ultimately stored.
Technical safeguards are where IT teams spend most of their implementation effort: enforcing unique logins and role-based access rather than shared credentials, maintaining audit logs sufficient to reconstruct who accessed what and when, and encrypting ePHI both at rest and in transit. See Microsoft 365 Security Baseline for how many of these technical safeguards map directly onto standard Microsoft 365 tenant configuration.
"Required" vs. "addressable" — the most misunderstood distinction in HIPAA
Every implementation specification under the Security Rule is labeled either required or addressable. "Required" is unambiguous — the organization must implement the specification, full stop. "Addressable" is where most confusion, and most audit exposure, actually happens.
"Addressable" is not optional
"Addressable" does not mean "optional" or "nice to have." It means the organization must do one of three things, and document which: (1) implement the specification as written, (2) implement an equivalent alternative measure that achieves the same protective outcome, or (3) formally document, with a reasoned justification, why neither the specification nor a reasonable alternative is appropriate given the organization's specific risk analysis. Simply skipping an addressable specification with no documentation is a Security Rule violation — the "addressable" label shifts the compliance obligation from a fixed action to a documented risk-based decision, it does not remove the obligation.
In practice, this means an organization cannot point to a checklist and say "that one was addressable, so we didn't do it." An auditor or investigator asking about an addressable specification expects either evidence of implementation, evidence of an equivalent control, or a documented risk-based rationale — and "we didn't think about it" satisfies none of the three.
Business associate agreements extend the obligation
Any vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity — a hosting provider, a billing service, an MSP with access to systems containing patient data — is a business associate, and is required to sign a Business Associate Agreement (BAA) that contractually extends Security Rule obligations to that vendor. A covered entity remains accountable for ePHI even when it's a vendor's system that's ultimately breached, which is why vendor selection and BAA management is itself an administrative safeguard, not a separate concern.
Why this matters beyond audit risk
HIPAA Security Rule compliance is increasingly a prerequisite for cyber insurance underwriting and for winning healthcare-adjacent contracts, independent of whether an organization has ever been directly audited by HHS. Documented risk analysis, access controls, and audit logging are exactly the kind of verifiable evidence that both insurers and enterprise healthcare partners now expect to see before doing business — treating the Security Rule as a governance framework rather than a compliance checkbox reflects that reality.
Common mistakes
- Treating "addressable" as "optional." As covered above, this is the single most common and most consequential misreading of the rule.
- Skipping the risk analysis and jumping straight to technical controls. Without a documented risk analysis, there's no defensible basis for the safeguards chosen — or the ones left out.
- Assuming cloud hosting transfers full responsibility to the vendor. A signed BAA obligates the vendor, but the covered entity remains accountable for overall compliance and for verifying the vendor's own safeguards.
- Neglecting physical and administrative safeguards in favor of only technical ones. All three categories are required; strong encryption doesn't offset an absent workforce training program or unrestricted facility access.
FAQ
Does the Security Rule apply to us if we don't directly treat patients? It applies to any covered entity or business associate that creates, receives, maintains, or transmits ePHI — this includes billing companies, IT providers, and other vendors handling ePHI on behalf of a healthcare organization, not just clinical providers themselves.
What counts as a valid "risk analysis" under the Security Rule? An accurate, thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI across all systems that touch it — it must be organization-specific, not a generic template, and it should be revisited when the environment changes materially.
Is encryption required or addressable? Encryption of ePHI in transit and at rest is addressable, but given the difficulty of justifying a reasonable alternative that achieves equivalent protection, most organizations implement it directly rather than attempt to document why it isn't necessary.