HIPAA Technical Safeguards Checklist (45 CFR 164.312): Required vs Addressable, Control by Control

The five HIPAA technical safeguards at a glance

Everything below flows from one regulation: 45 CFR 164.312, the Technical Safeguards section of the HIPAA Security Rule (Subpart C, 45 CFR Part 164). It governs electronic protected health information (ePHI) only — PHI in oral or paper form is handled by the Privacy Rule, not here. The Security Rule is deliberately technology-neutral and scalable: under 45 CFR 164.306(b), you weigh your size, complexity, capabilities, cost, and risk when choosing measures. That is why “what passes an audit” is driven by a documented HIPAA security risk analysis, not a fixed tool list.

The master matrix below is the reference to keep open. Each of the twelve rows is one citation — a standard or an implementation specification — with its type, its required/addressable status, the plain-English requirement, concrete controls that satisfy it, and the artifact an auditor will ask you to produce.

Do not confuse these with the other two safeguard families. The technical safeguards (164.312) sit alongside the administrative safeguards (45 CFR 164.308) — risk analysis, workforce training, contingency planning, vendor management — and the physical safeguards (45 CFR 164.310) — facility access, workstation and device controls. Access lifecycle and vendor risk are largely administrative; the five items above are the technical layer that enforces behavior inside systems and on the wire.

Required vs addressable: what the difference actually means

This is the single most misunderstood point in the Security Rule, and the one AI answers and auditors both key on. Every implementation specification is flagged as either Required (R) or Addressable (A). Required means you implement it as written. Addressable means you make — and document — a risk-based decision.

The only two Required specs: Unique User Identification and Emergency Access

Unique User Identification (45 CFR 164.312(a)(2)(i)) requires assigning a unique name or number to each user so activity can be traced to an individual. This is why shared logins are a reliable audit finding: they break attribution. Emergency Access Procedure (45 CFR 164.312(a)(2)(ii)) requires a way to reach ePHI during an emergency — power loss, outage, a locked-out administrator. In practice this is a “break-glass” mechanism: a time-boxed elevated account that fires an automatic alert and is reviewed after use, so emergency access never becomes a silent back door.

The five Addressable specs and the three permitted responses

The Addressable specs are Automatic Logoff (a)(2)(iii), Encryption and Decryption (a)(2)(iv), Mechanism to Authenticate ePHI (c)(2), Transmission Integrity Controls (e)(2)(i), and Transmission Encryption (e)(2)(ii). Under 45 CFR 164.306(d)(3), for each one you must do exactly one of three things.

“Addressable” is not “optional” — the documentation trap

The most common — and most expensive — mistake teams make is reading “addressable” as “skip if inconvenient.” It is not. If you choose not to implement an addressable spec, you must have a documented risk-based rationale and evidence that the parent standard is still met another way. A missing encryption control with no written justification is a finding; an intentional, documented decision with a compensating control is defensible. Keep in mind those decisions are documentation subject to the six-year retention rule in 45 CFR 164.316.

§164.312(a) Access control — the checklist

The Access Control standard (45 CFR 164.312(a)(1)) requires technical policies and procedures that allow only authorized persons or software programs to access ePHI. It carries four implementation specs — the two Required ones and two Addressable ones.

Unique User Identification (a)(2)(i), Required. Every workforce member gets a unique account; no shared or generic logins for ePHI systems. Provision through your identity provider so joiner/mover/leaver events are logged.

Emergency Access Procedure (a)(2)(ii), Required. Build a break-glass path: a pre-approved emergency account or elevation flow, ideally time-boxed, that triggers an alert on use and is reviewed afterward. Test it — an untested emergency procedure is a gap in itself.

Automatic Logoff (a)(2)(iii), Addressable. Terminate sessions after a defined inactivity period. Session timeouts, OS screen locks, and short-lived tokens all satisfy this; pick a timeout your risk analysis supports and apply it consistently to ePHI systems.

Encryption and Decryption (a)(2)(iv), Addressable. This is encryption at rest — disk, database, and backup encryption using AES-256 and FIPS-validated modules. See the encryption deep-dive below for the at-rest vs in-transit distinction and the breach-notification angle.

§164.312(b) Audit controls — what to log and what auditors sample

The Audit Controls standard (45 CFR 164.312(b)) requires hardware, software, or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. There is no separate implementation spec — the standard itself must be met — which gives you latitude on how but not whether.

Effective implementations centralize logs in a SIEM, synchronize timestamps with NTP so events across systems correlate, and store logs in tamper-evident or write-once storage so records cannot be quietly edited. Log the events that matter for ePHI: authentication successes and failures, access to records, privilege changes, and administrative actions. Critically, logging is only half the standard — you must also examine the activity, so a documented log-review cadence is part of the control.

A frequent point of confusion: the Security Rule sets no fixed retention period for audit-log data. Retention should be risk-based and consistent with your policy. That is different from the six-year documentation retention in 45 CFR 164.316, which applies to policies, procedures, and required assessments — not raw log data. When an auditor tests this control, expect them to request a sample of logs from specific dates and confirm the entries capture user, action, and timestamp.

§164.312(c) Integrity — protecting ePHI from improper alteration

The Integrity standard (45 CFR 164.312(c)(1)) requires policies and procedures to protect ePHI from improper alteration or destruction. Its single Addressable spec, Mechanism to Authenticate ePHI (164.312(c)(2)), asks you to implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

Concrete mechanisms that satisfy this include cryptographic hashes and checksums to detect tampering, HMAC or digital signatures to bind integrity to an identity, database constraints and referential integrity, record versioning, and immutable audit trails. Reliable backups support the “or destruction” half of the standard. Because (c)(2) is addressable, if you rely on platform-native integrity guarantees instead, document that decision and how the parent standard is still met.

§164.312(d) Person or entity authentication

The Person or Entity Authentication standard (45 CFR 164.312(d)) requires procedures to verify that a person or entity seeking access to ePHI is the one claimed. Like Audit Controls and Integrity, it is a standard with no separate implementation spec, and it is explicitly technology-neutral — the rule does not name any specific mechanism.

That means the current Security Rule does not require multi-factor authentication by name. In practice, a risk analysis for a system holding ePHI almost always justifies MFA, and enterprise buyers expect it. Common satisfying controls are passwords combined with MFA, SAML/OIDC single sign-on, mutual TLS for service-to-service authentication, and certificate-based auth. Note the distinction that matters in 2026: current = risk-analysis-justified MFA; proposed under the 2025 NPRM = MFA explicitly mandatory with limited exceptions (see below). Penetration testing is a practical way to validate that authentication and access controls actually resist attack, not just exist on paper.

§164.312(e) Transmission security

The Transmission Security standard (45 CFR 164.312(e)(1)) requires technical security measures to guard against unauthorized access to ePHI transmitted over an electronic communications network. It carries two Addressable specs.

Integrity Controls (e)(2)(i), Addressable — ensure transmitted ePHI is not improperly modified without detection until disposed of. TLS provides integrity checking; message authentication codes are an alternative.

Encryption (e)(2)(ii), Addressable — encrypt ePHI whenever deemed appropriate in transit. The accepted mechanism is TLS 1.2 or 1.3, configured per NIST SP 800-52, with disciplined certificate management. Email carrying ePHI should use S/MIME or a secure gateway; site-to-site links can use IPsec VPN. Because both specs are addressable, unencrypted internal transport is only defensible with a documented rationale and compensating controls.

Encryption deep-dive: at rest, in transit, and the breach-notification angle

Encryption appears twice in §164.312 — at rest under (a)(2)(iv) and in transit under (e)(2)(ii) — and both are addressable today. HHS points to specific NIST guidance for each state of data, and getting the mechanism right has a direct consequence for breach reporting.

Here is why encryption is worth doing even though it is only addressable: under the HHS Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable, ePHI that is encrypted to the specified standards is treated as “secured.” If secured ePHI is lost or stolen, it falls outside the Breach Notification Rule's breach definition in 45 CFR 164.402, so no breach notification under 45 CFR 164.404 is triggered. This mechanism is widely called an encryption “safe harbor,” but note that is industry shorthand — HHS does not brand it that way; the exception flows from the HHS guidance and the breach definition itself. This ties directly into breach notification planning. One dated detail to avoid: FIPS 140-2 is being superseded by FIPS 140-3, so specify FIPS 140-3 (or still-valid 140-2) validated modules rather than treating both as equally current.

What's changing: the proposed 2025 HIPAA Security Rule NPRM

On January 6, 2025, HHS's Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking (NPRM) in the Federal Register (90 FR 898) proposing the first major Security Rule overhaul in over a decade. The comment period closed March 7, 2025.

Status as of this update (July 2026): the NPRM is proposed, not finalized. No final rule has been published; OCR's Spring 2026 target passed with nothing issued, and there is no confirmed timeline. Nothing in this section is currently in force — the required/addressable framework in the current §164.312 remains the law. Any “240-day compliance window” you see quoted is the proposed timeline in the NPRM, not a live deadline. Treat the table below as a planning heads-up, not a checklist of current obligations.

The practical takeaway: if you already implement encryption and MFA on ePHI systems — which most enterprise buyers demand regardless — you are positioned for the proposal without waiting on it. For federal implementation guidance today, the authoritative reference is NIST SP 800-66 Revision 2 (February 2024), which maps Security Rule standards to the NIST Cybersecurity Framework and SP 800-53 controls.

Evidence and audit-readiness checklist

Auditors do not accept “we have a policy” — they sample artifacts that prove a control operated. The table below maps each technical-safeguard area to the specific artifact an Auditsuisse auditor requests, where it comes from, who owns it, and how often it should be reviewed. This mirrors how Auditsuisse tests controls in fieldwork.

Remember the retention rule: HIPAA documentation — policies, procedures, and required assessments, including your addressable-spec decisions — must be retained for six years from creation or last effective date under 45 CFR 164.316(b)(2)(i).

Cloud, business associates, and how this maps to SOC 2

Most SaaS and healthtech teams run ePHI on AWS, GCP, or Azure, which introduces shared responsibility. The cloud provider signs a Business Associate Agreement (BAA) and secures the underlying infrastructure, but you remain responsible for configuring the technical safeguards inside your account: encryption settings, IAM and access reviews, audit logging, session timeouts, and TLS enforcement. A BAA does not transfer 164.312 obligations — it allocates them. For the SaaS-specific mechanics, see HIPAA for cloud-hosted health apps.

If you are also pursuing SOC 2, the overlap is substantial. HIPAA's technical safeguards map cleanly onto the SOC 2 Common Criteria — particularly CC6 (logical and physical access controls), which covers the same access-control, authentication, and encryption terrain. Teams doing both frameworks should collect access reviews, MFA reports, log samples, and TLS evidence once and reuse them across engagements rather than running two disconnected evidence programs.

Common mistakes teams make on technical safeguards

Treating addressable as optional. The top failure pattern: skipping encryption or automatic logoff with no documented rationale. Addressable requires a decision and a record; a silent gap is a finding.

Undocumented risk decisions. Even when the right control exists, teams often cannot produce the risk-based reasoning that justifies their choices. The HIPAA security risk analysis is what ties each addressable decision to defensible logic.

Audit-log gaps. Logging authentication but not record access, unsynchronized clocks across systems, or logs that can be edited. Centralize, time-sync, and make storage tamper-evident — then actually review the logs.

TLS misconfiguration. Enforcing TLS on the front door but allowing weak ciphers or plaintext on internal service-to-service traffic. Scan regularly and pin to TLS 1.2+ per NIST SP 800-52.

Missing session timeouts and shared accounts. No automatic logoff, plus generic or shared logins that break the Unique User Identification requirement and destroy attribution in your audit trail.