HIPAA Security Risk Assessment Checklist Template

The most common reason OCR rejects a risk analysis is scope. If a system holds ePHI and is not in the inventory, it is not in the analysis.

• Name the assessment lead and confirm the Security Official — who runs the assessment and who approves it
• Define the scope — every location, workforce group, system, device and vendor that creates, receives, maintains or transmits ePHI, including remote staff
• Pull last year’s risk register and risk management plan — record which actions closed and which are still open
• Update the ePHI asset inventory — EHR, billing, imaging, email, file shares, backups, laptops, phones, connected medical devices and cloud services
• Map how ePHI flows — where it enters, where it is stored, who it is sent to and which business associates handle it
• Record what has changed since the last assessment — new systems, sites, vendors, mergers or incidents

• List the reasonably anticipated threats to each asset — ransomware, phishing and credential theft, insider misuse, lost or stolen devices, vendor compromise, fire, flood and power loss
• Gather technical evidence — the latest vulnerability scan, penetration test results, unsupported software and patch status
• Review the year’s security incident and breach log — incidents show which threats are real for you, not in theory
• Interview system owners and department leads — shared logins, workarounds, unapproved apps and paper-to-digital gaps
• Record each threat and vulnerability pair against the asset it affects

• Access controls — unique user IDs, role-based access, prompt removal of leavers, and MFA for remote and privileged access
• Encryption — ePHI at rest on servers, laptops, phones and backups, and in transit over email and interfaces
• Audit controls — logging switched on for ePHI systems, and the logs actually reviewed
• Backup and recovery — backups isolated from the network, restores tested and recovery times known
• Physical safeguards — facility access, workstation placement, and device and media disposal
• Business associate agreements — a current BAA for every vendor in the ePHI inventory
• Addressable specifications — document whether each is implemented, replaced by an equivalent measure or not reasonable, and why

• Rate the likelihood of each threat exploiting each vulnerability, given the safeguards already in place — Low, Moderate or High
• Rate the impact if it happens — patient safety, records affected, downtime, and regulatory and financial exposure
• Combine the two into a risk level using the matrix below — one scale, applied the same way to every risk
• Enter every risk in the register — asset, threat, vulnerability, existing controls, likelihood, impact and risk level
• Security Official reviews the ratings for consistency — challenge any rating the evidence does not support
• Record whether any risk is rated High — this answer switches on Phase 6

• Decide a treatment for every risk — mitigate, transfer, avoid or accept, with the reason recorded
• Give each mitigation an owner, a target date and an estimated cost
• Document accepted risks with the rationale and the approver — acceptance is a decision, not an omission
• Prioritise the plan by risk level and set progress review dates for the Security Official
• Brief leadership on the plan and the budget it needs

Shown only when Phase 4 records at least one High risk. Conditional logic keeps these tasks out of the way when there is nothing urgent to fix.

• Put interim safeguards in place for each High risk within the deadline you set — for example, close an exposed service, enforce MFA or isolate a legacy device
• Open a remediation project for each High risk, with milestones and a named owner
• Verify each fix with evidence — a rescan, a configuration export or a successful restore test
• Re-rate the risk after remediation and update the register
• Escalate any High risk still open at its target date to leadership

Assigned to the Security Official by name. The analyst who compiled the register should not approve it.

• Compile the risk analysis report — scope, method, inventory, register, risk management plan and conclusions
• Security Official and leadership approve the report — record who approved it and when
• Retain the report, register and evidence for at least six years from the date created or last in effect, whichever is later
• Feed the findings into security awareness training and the policies they affect
• Schedule next year’s assessment and record the events that trigger an earlier update — a new EHR, a new site, a merger or a significant incident