HIPAA Security Rule: Technical Safeguards Checklist

In February 2024, Change Healthcare suffered a ransomware attack that exposed the protected health information of over 100 million individuals --- the largest healthcare data breach in U.S. history. OCR's subsequent investigation revealed failures in basic technical safeguards: missing multi-factor authentication on a remote access portal, inadequate network segmentation, and audit logging gaps that delayed breach detection by weeks. The settlement discussions are ongoing, but the enforcement signal is unmistakable.

The HIPAA Security Rule (45 CFR Part 160 and Subparts A and C of Part 164) is not abstract regulation. It is a specific, enumerable set of safeguards that OCR tests against when something goes wrong --- and OCR enforcement has accelerated since 2023, with a particular focus on technical safeguard deficiencies that should have prevented or limited breach scope.

This article provides a practitioner-level checklist of the technical safeguards, the risk analysis that underpins them, and the enforcement context that makes each one worth implementing before OCR comes asking questions.

Safeguard Categories

The Security Rule organizes requirements into three categories. This article focuses on technical safeguards --- the most concrete, measurable, and frequently cited in enforcement actions --- but they do not exist in isolation.

Category	Focus	Examples
Administrative	Policies, procedures, workforce management	Risk analysis, workforce training, contingency planning
Physical	Facility and device protection	Facility access controls, workstation security, device disposal
Technical	Technology-based controls	Access controls, encryption, audit logging, integrity controls

The administrative safeguards (particularly risk analysis) provide the foundation. The technical safeguards provide the enforcement mechanism. Organizations that implement technical controls without conducting a risk analysis first typically implement the wrong controls in the wrong places --- and cannot justify their choices when OCR asks "why did you do it this way?"

Technical Safeguards Checklist

Access Control (164.312(a)(1))

The standard requires implementing technical policies and procedures to allow access to ePHI only to authorized persons and software programs. This is where Change Healthcare failed, and where OCR has extracted settlements exceeding $5 million from individual organizations.

Required implementations:

• Unique User Identification --- Assign a unique identifier to each user for tracking access
• Emergency Access Procedure --- Establish procedures for obtaining ePHI during emergencies
• Automatic Logoff --- Implement session timeouts that terminate sessions after inactivity
• Encryption and Decryption --- Implement mechanisms to encrypt and decrypt ePHI (addressable but strongly recommended)

Practical checklist:

• Every user has a unique login --- no shared accounts, no shared credentials
• Emergency access procedures documented, tested annually, and audit-logged when invoked
• Automatic session timeout configured (15-30 minutes typical; clinical workflows may justify longer with compensating controls)
• ePHI encrypted at rest using AES-256 or equivalent FIPS 140-2 validated module
• Role-based access control (RBAC) limits access to minimum necessary
• Access provisioning and deprovisioning procedures documented with SLA for termination (same-day for involuntary separations)
• Multi-factor authentication on all remote access paths (not addressable in practice --- OCR treats MFA absence as de facto noncompliance post-Change Healthcare)

Audit Controls (164.312(b))

Organizations must implement hardware, software, and procedural mechanisms to record and examine access to ePHI. The six-year retention requirement catches organizations off-guard --- most SIEM deployments default to 90-day hot storage.

Practical checklist:

• Audit logging enabled on all systems storing or accessing ePHI
• Logs capture who accessed what, when, from where, and what action was taken
• Log retention policy defined and implemented (minimum 6 years per HIPAA record retention requirement)
• Logs protected from modification or deletion (append-only storage, integrity hashing)
• Regular log review process in place with defined cadence and responsible party
• Alerting configured for suspicious access patterns (bulk record access, after-hours queries, privilege escalation)
• Log aggregation across all ePHI systems into a central SIEM or equivalent

Integrity Controls (164.312(c)(1))

Organizations must implement policies and procedures to protect ePHI from improper alteration or destruction. This safeguard is increasingly relevant as ransomware actors shift from exfiltration to data manipulation --- a tampered medical record is potentially more dangerous than a stolen one.

Practical checklist:

• Data integrity validation mechanisms in place (checksums, digital signatures, database-level constraints)
• Change detection on critical files and databases containing ePHI
• Backup integrity verification procedures (restore tests, not just backup job success logs)
• Anti-malware protection on systems handling ePHI with behavioral detection capabilities
• Database audit trails for modifications to ePHI records (who changed what, when, previous value)
• Immutable backup copies stored offline or in write-once storage

Person or Entity Authentication (164.312(d))

Verify the identity of persons or entities seeking access to ePHI. Post-Change Healthcare, this is the safeguard where OCR scrutiny has intensified most dramatically.

Practical checklist:

• Multi-factor authentication for all remote access to ePHI systems
• Phishing-resistant MFA (FIDO2/WebAuthn) for privileged accounts and administrative access
• Strong password policies enforced technically (NIST 800-63B guidance: minimum 8 characters, no composition rules, check against breach databases)
• Authentication mechanisms for application-to-application access (service accounts, API keys, certificates)
• Certificate-based authentication where appropriate (clinical devices, system interconnections)
• Failed login lockout policies with account recovery procedures that verify identity

Transmission Security (164.312(e)(1))

Protect ePHI transmitted over electronic communications networks. With the proliferation of telehealth, API-driven clinical integrations, and cloud-hosted EHR systems, transmission security now covers far more surface area than it did when the rule was written.

Practical checklist:

• TLS 1.2 or higher for all ePHI in transit (TLS 1.3 preferred; TLS 1.0/1.1 must be disabled)
• VPN or encrypted tunnel for remote access to clinical systems
• Email encryption for ePHI (S/MIME, TLS enforcement, or portal-based secure messaging)
• Secure file transfer protocols (SFTP, FTPS) for ePHI exchange with business associates
• Wireless network encryption (WPA3 or WPA2-Enterprise with RADIUS authentication)
• API security for clinical integrations (OAuth 2.0, mutual TLS, encrypted payloads)

The "Required" vs "Addressable" Distinction

HIPAA uses two implementation designations:

• Required --- Must be implemented as specified
• Addressable --- Must be assessed; if reasonable and appropriate, must be implemented; if not, must document why and implement an equivalent alternative

Here is the hard-won opinion every HIPAA consultant should be giving their clients: "Addressable" does not mean "optional," and in practice, OCR has never accepted a risk acceptance for encryption or MFA from an organization that subsequently suffered a breach. The regulatory text allows for risk-based exclusion. The enforcement reality does not. Implement encryption and MFA as if they were required specifications --- because in any post-breach investigation, they effectively are.

Risk Analysis: The Foundation That Most Organizations Get Wrong

The single most important requirement in the Security Rule is the risk analysis (164.308(a)(1)(ii)(A)). Everything else flows from it. OCR has cited inadequate risk analysis in more enforcement actions than any other single deficiency.

A proper risk analysis:

1. Identifies all ePHI --- every system, application, database, file share, backup tape, and endpoint where ePHI exists or transits
2. Identifies threats --- unauthorized access, data loss, ransomware, insider threat, natural disaster, vendor compromise
3. Identifies vulnerabilities --- unpatched systems, misconfigured access controls, missing encryption, inadequate logging
4. Assesses current controls --- what protections are already in place and how effective they are
5. Determines likelihood and impact --- how likely is each threat-vulnerability pair, and what would the impact be to patients and the organization
6. Assigns risk levels --- prioritize risks for remediation based on the combination of likelihood and impact

The risk analysis must be updated whenever significant changes occur --- new systems, new vendors, new clinical workflows, or after any security incident. OCR expects a living document, not an annual checkbox exercise.

Breach Notification Obligations

The HIPAA Breach Notification Rule (164.400-414) requires covered entities to notify affected individuals, HHS, and in some cases the media, following a breach of unsecured PHI. Breach notification timelines are strict and non-negotiable:

• 500+ individuals affected: Notify HHS and prominent media within 60 days of discovery
• Fewer than 500: Notify affected individuals within 60 days; notify HHS annually (calendar year aggregation)

PHI is considered "unsecured" if it is not rendered unusable, unreadable, or indecipherable through encryption or destruction per HHS guidance. This creates the single strongest business case for encrypting all ePHI --- encrypted data that is breached is generally exempt from notification requirements under the safe harbor provision. Every dollar spent on encryption is a dollar potentially saved on breach notification, credit monitoring, OCR settlements, and reputational damage.

Penalties and Enforcement Trends

HIPAA violations carry significant penalties under four tiers:

Tier	Violation Type	Penalty Per Violation	Annual Maximum
1	Unknowing	$137 - $68,928	$34,464
2	Reasonable cause	$1,379 - $68,928	$137,886
3	Willful neglect (corrected)	$13,785 - $68,928	$344,638
4	Willful neglect (not corrected)	$68,928	$2,067,813

Note: Penalty amounts are adjusted annually for inflation. The figures cited reflect the 2023 adjustments; current amounts are modestly higher.

OCR enforcement actions have resulted in settlements exceeding $16 million for systemic failures. The trend since 2023 is toward larger settlements and more aggressive pursuit of technical safeguard deficiencies --- particularly MFA, encryption, and access control failures.

HIPAA and Related Frameworks

Organizations subject to HIPAA often face additional compliance requirements that overlap significantly:

• HITRUST --- The HITRUST CSF incorporates HIPAA requirements and maps them alongside 40+ other frameworks. HITRUST r2 certification is increasingly the market standard for healthcare vendor assurance.
• SOC 2 --- Many technical safeguards overlap with SOC 2 Trust Service Criteria, particularly in access control, monitoring, and availability domains
• NIST CSF --- The NIST Cybersecurity Framework provides a complementary risk-based approach that maps cleanly to HIPAA's safeguard structure
• State laws --- Many states have additional health data protection requirements (California CMIA, New York SHIELD Act, Texas HB 300)

A multi-framework compliance approach lets you address HIPAA alongside these related standards without duplicating effort --- implement once, evidence once, satisfy multiple frameworks simultaneously.

Key Takeaways

• The risk analysis is the foundation --- OCR cites it in more enforcement actions than any other deficiency
• "Addressable" does not mean "optional" --- treat encryption and MFA as required specifications
• Six-year log retention is mandatory and catches most organizations unprepared
• Encrypting all ePHI triggers the breach notification safe harbor --- the single best risk reduction investment
• Post-Change Healthcare, OCR treats MFA absence as de facto noncompliance for remote access
• Technical safeguards do not exist in isolation --- they must trace back to your documented risk analysis

Frequently Asked Questions

Is encryption required or addressable under the Security Rule?

Encryption is technically "addressable" under 164.312(a)(2)(iv) for data at rest and 164.312(e)(2)(ii) for data in transit. However, in practice, OCR has never accepted a risk-based exclusion for encryption from an organization that subsequently suffered a breach. More importantly, encryption triggers the breach notification safe harbor --- encrypted ePHI that is accessed by unauthorized parties generally does not require breach notification. Implement encryption as if it were required.

How often must we conduct the risk analysis?

The Security Rule requires the risk analysis to be "ongoing" and updated whenever the environment changes significantly --- new systems, new vendors, new workflows, organizational changes, or after security incidents. OCR has penalized organizations for treating risk analysis as an annual checkbox exercise. Best practice is continuous risk assessment with formal documentation updates at least annually and after any significant change.

What audit log retention period does HIPAA require?

HIPAA requires six years of documentation retention (164.530(j)), which includes audit logs that demonstrate compliance with Security Rule requirements. Most SIEM deployments default to 90 days of hot storage, which is grossly insufficient. Implement tiered storage (hot/warm/cold) that maintains six years of ePHI access logs in an immutable, queryable format.

Does HIPAA require multi-factor authentication?

The Security Rule does not explicitly name MFA --- it requires "person or entity authentication" (164.312(d)). However, OCR enforcement actions since 2023 have consistently cited MFA absence as a contributing factor in breaches involving remote access. After the Change Healthcare breach (single-factor remote access enabled the initial compromise), MFA for remote access is effectively a de facto requirement regardless of the formal language.

How do the technical safeguards apply to cloud-hosted systems?

Cloud-hosted ePHI systems require a Business Associate Agreement (BAA) with the cloud provider, and the covered entity remains responsible for ensuring all technical safeguards are implemented --- whether by the entity, the cloud provider, or shared between them. Document the responsibility split in your risk analysis: which safeguards are yours, which are the provider's, and how you verify the provider's implementation. The shared responsibility model does not transfer compliance accountability.

How Advisedly Helps

Advisedly maps all HIPAA Security Rule requirements --- administrative, physical, and technical --- alongside your other compliance obligations in a single platform. The platform tracks implementation status for each safeguard, attaches evidence, and maintains the living risk analysis documentation that OCR expects during an investigation. Automated evidence collection captures access control configurations, encryption status, audit log settings, and MFA enrollment from your infrastructure on an ongoing basis, reducing the manual documentation burden that makes compliance programs brittle. For organizations managing HIPAA alongside HITRUST, SOC 2, or other frameworks, Advisedly cross-maps controls across 500+ frameworks so a single implementation satisfies multiple standards simultaneously. Contact begin@advisedly.ai

<!-- LI hook: Change Healthcare failed on basic MFA. Here is the full technical checklist. -->