HIPAA Security Rule Risk Analysis Checklist: A Practical Checklist

Summary. The risk analysis is the foundational Security Rule requirement and the most frequently cited failure in OCR enforcement, and the reason is almost always scope rather than effort — organizations analyze the electronic health record and omit the imaging system, the research database, the billing vendor, the shared drives, and the laptops. This checklist runs an enterprise-wide analysis in the sequence the regulation contemplates: inventory every system and location holding ePHI, identify threats and vulnerabilities, assess existing safeguards, determine likelihood and impact, and document. Later phases cover risk management, the addressable specifications, and the review cycle.

What this checklist is for. Conducting the risk analysis required by 45 C.F.R. § 164.308(a)(1)(ii)(A), enterprise-wide, in a form that would satisfy an OCR investigator. For the surrounding framework, see HIPAA Privacy and Security Compliance for Covered Entities and Business Associates.

Phase 1 — Scope and governance

Confirm the organization's status — covered entity, business associate, or hybrid entity with designated health care components — and the boundaries of what is in scope.
Designate the security official required by 45 C.F.R. § 164.308(a)(2), with authority and resources, and document the appointment.
Assemble the analysis team: information security, IT operations, clinical or business owners, compliance, privacy, and legal.
Decide whether to conduct the analysis under counsel for privilege, recognizing that the analysis itself must be documented and retained and will be produced to OCR on request.
Select a methodology and document it — NIST SP 800-30 and the HHS guidance on risk analysis are the usual references.
Set a schedule, and identify who signs off.

Phase 2 — Inventory every location of ePHI

This phase determines whether the analysis is adequate. Incomplete scope is the defect OCR cites.

Clinical systems — the electronic health record, and every ancillary system: laboratory, radiology and PACS, pharmacy, cardiology, pathology, anesthesia, oncology, dental, and behavioral health.
Business systems — practice management, billing and revenue cycle, scheduling, patient portal, telehealth platform, transcription, coding, and denial management.
Communication — email, secure messaging, fax servers, voicemail, call recording, and any collaboration platform where staff share patient information.
Storage — file shares, SharePoint and equivalent, cloud storage, databases, data warehouses, and backup media including tapes and off-site copies.
Endpoints — workstations, laptops, tablets, smartphones (company and personal under BYOD), workstations on wheels, and kiosks.
Medical devices that store or transmit ePHI — infusion pumps, monitors, imaging modalities, and anything on the clinical network.
Removable media — USB drives, external disks, and optical media.
Physical locations of servers, network closets, and any paper generated from electronic systems.
Third parties — every business associate, subcontractor, cloud host, and vendor with access, and where the data resides for each.
Shadow IT — survey departments for tools acquired outside procurement, which is where the unexpected repositories are.
Build a data flow map for each system: how ePHI enters, where it is stored, where it moves, who accesses it, and how it leaves.

Why this matters. OCR resolution agreements repeatedly describe entities that had "a risk analysis" limited to a subset of their environment. An enterprise-wide inventory, dated and maintained, is what distinguishes an adequate analysis from a cited one.

Phase 3 — Identify threats and vulnerabilities

For each system or grouping identified in Phase 2:

Human threats — malicious insiders, curious staff, credential theft, phishing, social engineering, ransomware and other malware, and unauthorized third-party access.
Natural threats — fire, flood, storm, and earthquake, weighted by geography.
Environmental threats — power failure, HVAC failure, and water intrusion.
Technical vulnerabilities — unsupported or unpatched software, default or shared credentials, absent multifactor authentication, unencrypted data at rest and in transit, excessive privileges, absent or unreviewed logging, insecure interfaces and APIs, and unsegmented networks.
Process vulnerabilities — no termination checklist, no periodic access review, no media disposal procedure, no vendor oversight, untested backups.
Physical vulnerabilities — unsecured server rooms, unattended workstations in public areas, and unlocked medication or records storage.
Use real inputs: vulnerability scans, penetration test results, prior incidents and near misses, audit findings, and threat intelligence relevant to health care.

Phase 4 — Assess current safeguards

Document the administrative safeguards in place: policies, sanction policy, workforce clearance and termination procedures, access authorization, training, incident procedures, contingency plan, and business associate agreements.
Document the physical safeguards: facility access controls, workstation use and security policies, and device and media controls including disposal and reuse.
Document the technical safeguards: unique user identification, emergency access, automatic logoff, encryption at rest and in transit, audit controls, integrity controls, authentication, and transmission security.
Distinguish controls that exist on paper from controls that are operating — test a sample rather than accepting a policy as evidence.
Note where a control is partially deployed, and to which systems, because that is where the residual risk sits.

Phase 5 — Determine likelihood, impact, and risk

For each threat-vulnerability pair, assess likelihood of occurrence given the safeguards in place.
Assess impact — the volume and sensitivity of ePHI affected, the effect on care delivery, financial consequences, and regulatory exposure.
Combine into a risk level using the documented methodology, on a consistent scale.
Rank the risks, and record the reasoning, not merely the rating.
Have the security official and, for significant findings, senior management review and sign off.

Why this matters. The regulation requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. A rating with no supporting analysis is not an assessment, and it will not survive an investigator's questions about how the number was reached.

Phase 6 — Risk management and the addressable specifications

Under § 164.308(a)(1)(ii)(B), implement security measures sufficient to reduce risks to a reasonable and appropriate level, and document the plan with owners and dates.
For each required implementation specification, confirm it is implemented.
For each addressable specification, document one of three outcomes: implemented; not reasonable and appropriate with the rationale and an equivalent alternative measure implemented; or not reasonable and appropriate with the rationale and no alternative. "Addressable" does not mean optional, and an addressable specification that is neither implemented nor documented is a violation.
Prioritize the controls with the highest return: encryption of laptops, mobile devices, removable media, backups, and transmissions — which is also the breach notification safe harbor; multifactor authentication; role-based access with periodic review; audit logging and actual log review; tested backups; and email security.
Confirm business associate agreements exist for every vendor identified in Phase 2, and that they include breach notification timing, security requirements, subcontractor flow-down, and return or destruction on termination.
Confirm the contingency plan — data backup, disaster recovery, emergency mode operation — exists and has been tested, including a timed restoration.
Confirm incident response procedures include the four-factor breach risk assessment and the notification clocks.

Phase 7 — Document, retain, and review

Produce a written report: scope, methodology, inventory, threats and vulnerabilities, current safeguards, risk determinations, and the risk management plan.
Retain the analysis and all supporting documentation for six years from creation or last effective date, per § 164.316(b)(2)(i).
Track remediation to completion, with evidence.
Review and update the analysis periodically and on any material change — a new system, a new vendor, a merger, a new location, a significant incident, or a material change in operations or technology. Annual review is the common practice and the defensible minimum.
Re-run a gap assessment against the Security Rule's standards after each material change.
Report to the board or governing body on the program's status, and document that it was reported.

Common mistakes

Scoping to the EHR only, omitting ancillary systems, vendors, endpoints, and backups.
Confusing a gap assessment with a risk analysis — a checklist against the regulation is not an analysis of threats, vulnerabilities, likelihood, and impact.
Buying a vendor questionnaire and treating the output as the analysis.
Rating risks without documenting the reasoning.
Leaving addressable specifications undocumented rather than implemented or justified.
Never updating — an analysis dated four years ago describes an environment that no longer exists.
No risk management plan, so the analysis identifies risks nobody remediates.
Failing to encrypt portable devices and backups, which forfeits the breach safe harbor.
Missing business associate agreements for vendors identified during the inventory.
Never testing a restoration, so the contingency plan is untested when it matters.

Primary authority

Statutes and regulations: HIPAA, 42 U.S.C. §§ 1320d–1320d-9; the Security Rule, 45 C.F.R. §§ 164.302–164.318, particularly §§ 164.306 (general rules and the flexibility of approach), 164.308 (administrative safeguards), 164.310 (physical safeguards), 164.312 (technical safeguards), 164.314 (organizational requirements), and 164.316 (policies, procedures, and documentation); the Breach Notification Rule, 45 C.F.R. §§ 164.400–164.414; the enforcement provisions at 45 C.F.R. Part 160, Subparts C, D, and E; and civil and criminal penalties at 42 U.S.C. §§ 1320d-5 and 1320d-6.
Guidance: HHS Guidance on Risk Analysis Requirements under the HIPAA Security Rule; NIST SP 800-30 (risk assessment) and NIST SP 800-66 (implementing the Security Rule); and the HHS guidance on encryption and destruction rendering PHI unusable, unreadable, or indecipherable.

This checklist is educational and not legal advice. Security Rule obligations depend on the organization's size, complexity, and environment, and state law may impose additional requirements. Conduct any risk analysis with qualified healthcare privacy and security advisors.