HIPAA Security Rule readiness checklist

This checklist maps the current HIPAA Security Rule against the changes proposed by HHS in January 2025. Use it to find out where your organization stands today, before the final rule sets the clock running. It is organized by safeguard family, with a short self-assessment under each area.

A printable PDF version with checkboxes for each item is available: Download the HIPAA Security Rule Readiness Checklist (PDF).

How to use it

Work through each area and answer honestly. “Partially” counts as no. Where you answer no, note the system or process involved. When you are done, the notes are the start of your remediation plan, and the gaps in the first two sections are the ones to close first.

1. Risk analysis and management

The foundation of the Security Rule, and the most frequently cited deficiency in OCR enforcement.

We have a written risk analysis completed within the past 12 months.
It references a technology asset inventory that lists every system, device, application, and service that creates, receives, maintains, or transmits ePHI.
It includes a network map showing how ePHI moves between those systems and to vendors.
It identifies threats and vulnerabilities for each system, with likelihood and impact ratings.
It produces a prioritized list of remediation actions with owners and target dates.
We have a risk management plan that tracks those actions to completion.
We review and update the inventory, map, and risk analysis at least annually and after significant changes.

Proposed change: the inventory and network map become explicit requirements, the risk analysis must tie to them, and annual review is mandatory.

2. Access control and authentication

Every workforce member has a unique user ID. No shared accounts access ePHI.
Multi-factor authentication is enforced for all access to systems containing ePHI, including email, remote access, and cloud services.
Access is granted by role and reviewed at least annually.
Access is removed within one business day when a workforce member leaves or changes roles.
Privileged and administrative access is separate from everyday accounts and limited to those who need it.
Sessions lock or terminate after a defined period of inactivity.

Proposed change: MFA becomes required, with narrow exceptions. Access termination timing becomes explicit.

3. Encryption

ePHI is encrypted at rest on servers, databases, backups, laptops, mobile devices, and removable media.
ePHI is encrypted in transit, including email containing ePHI, file transfers, and connections between systems.
Encryption keys are managed with documented procedures for generation, storage, rotation, and revocation.
We know who can access and use each key, and that list is reviewed.

Proposed change: encryption at rest and in transit becomes required, with limited exceptions that must be documented.

4. Vulnerability management and testing

Vulnerability scans run against all systems with ePHI at least every six months.
Critical and high findings are remediated on a defined timeline.
Operating systems and applications are patched on a documented schedule, with exceptions tracked.
A penetration test is performed at least annually by a qualified tester.
Findings from scans and tests are tracked to remediation and retested.

Proposed change: semiannual scanning and annual penetration testing become explicit requirements.

5. Contingency planning and recovery

Backups of ePHI are performed on a defined schedule and stored separately from production systems.
Backups are protected against ransomware: offline, immutable, or isolated with separate credentials.
Restores are tested at least annually, and the results are documented.
We know which systems are critical, and we can restore them within 72 hours.
We have a written contingency plan covering emergency operations, data recovery, and return to normal.
The plan has been tested or exercised in the past year.

Proposed change: 72-hour restoration of critical systems becomes an explicit requirement, and testing becomes mandatory.

6. Incident response

We have a written incident response plan that defines roles, escalation, and communication.
Workforce members know how to report a suspected incident.
The plan addresses breach assessment and notification obligations under the Breach Notification Rule.
We have tested the plan with a tabletop exercise in the past year.
Security event logging is enabled on systems with ePHI, and logs are reviewed.

Proposed change: written incident response procedures and regular testing become required.

7. Workforce security and training

Workforce members receive security awareness training at hire and at least annually.
Training covers phishing, password and MFA practices, handling ePHI, and incident reporting.
Training completion is recorded.
Sanctions for policy violations are documented and applied.

8. Business associates and vendors

Every vendor that touches ePHI has a signed Business Associate Agreement.
We have assessed the security practices of business associates with significant ePHI access.
Business associates are required to notify us of security incidents within a defined timeframe.
Vendor access to our systems is inventoried and reviewed.

Proposed change: business associates must provide written verification of their technical safeguards at least annually.

9. Physical safeguards

Facilities, server rooms, and network closets housing ePHI systems have controlled physical access.
Workstation placement and screen locking limit unauthorized viewing of ePHI.
Devices and media containing ePHI are tracked, and disposal procedures sanitize them.

10. Policies, documentation, and compliance audit

Security policies and procedures are written, current, and approved.
Documentation of risk analysis, training, access reviews, testing, and incident response is retained for six years.
We conduct an internal audit of Security Rule compliance at least annually.
A named individual is responsible for the security program.

Proposed change: annual compliance audits become an explicit requirement.

What to do with the results

Count your “no” answers in sections 1 through 5. Those are the gaps most likely to appear in an enforcement action and the ones the proposed rule tightens most. Section 1 comes first: without a current risk analysis tied to an inventory, nothing else can be prioritized correctly.

If you would like an outside assessment, Sidechain’s HIPAA security risk assessment is built to the current requirement at 45 CFR § 164.308 and structured for the proposed changes. Most are completed in as little as two weeks. For context on what the proposal changes and why, read the proposed HIPAA Security Rule changes, and what to do before they are final.

This guide is general information, not legal advice. Review specific requirements and deployments with your own counsel and compliance team.