HIPAASecurityRuleBreakdown:The18TechnicalSafeguardsEveryPracticeMustImplement

The HIPAA Security Rule (45 CFR Part 164, Subpart C) is the only federal standard that specifies how covered entities and business associates must protect electronic protected health information. It is technology-neutral by design, but the requirements are not optional suggestions. The Office for Civil Rights (OCR) enforces them, and the 2024 proposed rulemaking signals that the addressable-versus-required distinction is being reevaluated — likely tightening, not loosening.

This article walks through every technical safeguard in the Security Rule, explains the practical implementation for a small or midsized practice, and flags the gaps we most often find during a healthcare IT assessment.

The Structure: Standards and Implementation Specifications

The Security Rule is organized into three categories — administrative, physical, and technical safeguards. This breakdown focuses on the technical standards, which include five standards and 18 implementation specifications. Each specification is labeled either Required (R) or Addressable (A). Addressable does not mean optional. It means you must either implement the specification, implement a reasonable alternative that achieves the same purpose, or document why the specification is not reasonable and appropriate for your environment. OCR has repeatedly fined practices that treated "addressable" as "ignorable."

Standard 1: Access Control (§164.312(a)(1))

Unique User Identification (R)

Every user who touches ePHI needs a unique identifier. No shared logins. No "frontdesk" accounts used by three receptionists. When an incident happens, you need to reconstruct who did what, and shared accounts make that impossible. The most common gap: shared MFA tokens on shared-terminal check-in kiosks. Solution is named accounts with fast-user-switching or a kiosk mode that still identifies the individual.

Emergency Access Procedure (R)

During a crisis — a ransomware event, a fire, a clinician who forgot their password during a code — you need a documented way to access ePHI. Break-glass accounts stored in a physical safe, monitored by SIEM alerts, with mandatory after-action review. This is required, not addressable.

Automatic Logoff (A)

Workstations must terminate ePHI sessions after a period of inactivity. For exam-room workstations, 10–15 minutes. For administrative PCs, 15–30. Implement via Windows Group Policy, Intune configuration profiles, or Jamf for Apple environments.

Encryption and Decryption (A)

Encrypt ePHI at rest. BitLocker on Windows endpoints, FileVault on macOS, full-disk encryption on every laptop and tablet. If encrypted to NIST standards, a lost device generally qualifies for the HHS safe-harbor — meaning no breach notification required. The economics alone justify universal rollout.

Standard 2: Audit Controls (§164.312(b))

Audit Controls (R)

This is one standard with one implementation specification, and it is where most practices quietly fail. The rule requires "hardware, software, and/or procedural mechanisms" to record and examine activity in systems containing ePHI. Translation: you need EHR audit logs enabled, retained for at least six years (the HIPAA retention period for documentation), and actually reviewed. "We have logs" is not compliance. "We review logs weekly for anomalous access, document the review, and investigate anomalies" is.

Common gaps we find: logs enabled but retention set to 30 days because storage was expensive; logs captured but never reviewed; no defined anomalous-access rules (access outside business hours, high-volume record access, access to VIP records by non-care-team staff).

Standard 3: Integrity (§164.312(c)(1))

Mechanism to Authenticate Electronic PHI (A)

You must have a way to verify that ePHI has not been altered or destroyed in an unauthorized manner. In most EHR systems, this is built in — cryptographic hashes on stored records, versioned documentation, tamper-evident audit trails. For file-share ePHI (imaging, scanned documents), this often requires explicit implementation via file integrity monitoring or WORM (write-once-read-many) storage.

Standard 4: Person or Entity Authentication (§164.312(d))

Authentication (R)

Verify that the person or system accessing ePHI is who they claim to be. The rule does not specify MFA, but OCR guidance since the 2018 Anthem settlement has made clear that single-factor authentication alone is no longer "reasonable and appropriate" for remote access or administrative accounts. MFA for all remote access, all admin accounts, and all access to cloud-hosted ePHI is now table stakes. Phishing-resistant MFA (FIDO2, WebAuthn) is the trajectory.

Standard 5: Transmission Security (§164.312(e)(1))

Integrity Controls (A)

Ensure ePHI is not improperly modified in transit. TLS 1.2 or higher on all connections. HMAC or digital signatures for high-sensitivity transmissions. Practical implementation: disable TLS 1.0/1.1 on every web-facing service, enforce HTTPS-only on patient portals, and validate certificates.

Encryption (A)

Encrypt ePHI in transit. This is the twin of at-rest encryption. TLS for portals and APIs, email encryption for PHI sent externally (Paubox, Virtru, Microsoft 365 Message Encryption), and encrypted VPN or zero-trust network access for remote workers.

The 2024 Proposed Rulemaking: Why "Addressable" Is Getting Tighter

In December 2024, HHS issued a notice of proposed rulemaking that, if finalized, would reclassify several addressable specifications as required — including encryption at rest, MFA, and audit log review. Practices that have been treating addressable as optional should assume the regulatory gap is closing. Implementing the current addressable specifications now is cheaper than retrofitting under an enforcement deadline.

Implementation Checklist for a Small Practice

• Unique named accounts for every clinical and administrative user
• Emergency break-glass procedure documented and tested annually
• Automatic logoff configured via GPO / Intune / Jamf
• Full-disk encryption on every endpoint, tracked in inventory
• EHR audit logs enabled, retained 6+ years, reviewed weekly with documented review
• MFA on EHR, email, VPN, and all cloud-hosted PHI systems
• TLS 1.2+ enforced on all transport, weak protocols disabled
• Encrypted email for external PHI transmission
• File integrity monitoring or WORM for non-EHR ePHI storage
• Annual risk analysis that specifically addresses each of the 18 specifications

Where Practices Get Caught on Audit

OCR's enforcement pattern is consistent. The most common findings in resolution agreements are: no documented risk analysis that addresses the Security Rule specifically, insufficient audit log review, lack of MFA on administrative accounts, and unencrypted mobile devices. If you close those four gaps, you close the majority of audit risk.

For a deeper look at how these safeguards sit inside a complete healthcare IT program — including the administrative and physical safeguards not covered here — see our Healthcare IT pillar page or schedule a compliance assessment with our team.