HIPAA Risk Analysis: What Covered Entities Must Do

What HIPAA Risk Analysis Requires

Under the HIPAA Security Rule, covered entities and business associates must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to electronic protected health information (ePHI). This is not a one-time checklist exercise; it is a continuous process that should revisit threats as the organization's environment changes. The analysis must be documented, reasonable in scope, and grounded in the organization's actual workflows, systems, and physical setting.

Risk analysis sits at the center of the administrative safeguards and provides the foundation for every subsequent security decision, from where to invest in controls to how to respond to a breach. Without it, a covered entity cannot know which threats are material or which safeguards are proportionate.

Core Steps in the Risk Analysis Process

The Department of Health and Human Services (HHS) does not prescribe a single methodology, but it expects a systematic approach. Organizations typically move through the following steps:

• Scope the analysis: Identify all systems, locations, and processes that create, receive, maintain, or transmit ePHI.
• Gather data: Review system documentation, access logs, physical access records, and incident reports.
• Identify threats and vulnerabilities: Consider both external actors and internal errors, and map where weaknesses exist.
• Assess likelihood and impact: Rate each threat-vulnerability pair using a consistent scale.
• Determine risk level: Combine likelihood and impact to prioritize risks.
• Document findings and actions: Record the analysis, the rationale for decisions, and any remediation steps taken.

What Regulators Look for in a Risk Analysis

OCR has consistently cited the absence or inadequacy of risk analysis as the most common violation in enforcement actions. Regulators evaluate whether the analysis is current, whether it covers all ePHI locations, and whether the organization acted on the findings. A stale analysis that has not been updated after a major system change or a new business associate relationship is treated as a failure, even if the original document looked thorough.

Documentation Expectations

Organizations should maintain a living risk analysis report that includes the methodology used, the systems in scope, the threat sources considered, the risk ratings assigned, and the decisions taken to accept, mitigate, or transfer each risk. Decisions to accept risk should be explicit and supported by documented rationale.

Common Pitfalls and How to Avoid Them

Risk analyses often fall short in predictable ways. Organizations may limit the scope to their IT systems while ignoring paper records that are later digitized, or they may rely on a single template year after year without updating it for changes in staffing, vendors, or technology. Another frequent gap is failing to involve the people who actually handle ePHI, which means the analysis misses workflow-level risks that a technical assessment alone would not surface.

To avoid these pitfalls, treat the analysis as a cross-functional activity that includes IT, compliance, privacy, clinical operations, and HR. Update it at least annually and whenever there is a material change to your environment.

Risk Analysis and the Broader Security Program

A risk analysis does not operate in isolation. It directly informs the selection of technical safeguards, such as access controls and encryption, and administrative safeguards, such as workforce training and incident response procedures. When the analysis identifies a high risk, the security management process must implement a reasonable and appropriate mitigation. If the organization chooses not to mitigate, it must document why the risk is being accepted and what compensating controls are in place.

Risk Analysis vs. Risk Management

Risk analysis is the diagnostic step; risk management is the ongoing treatment of the risks identified. The Security Rule requires both, and OCR expects the two activities to be linked in the documentation so that every material risk has a clear owner and a plan.

Building a Defensible Program

The best way to build a defensible HIPAA risk analysis program is to use a recognized framework as a guide, document every decision, and keep the analysis tied to actual business operations. Whether an organization conducts the work internally or engages a qualified external assessor, the output should be a clear, actionable set of priorities that leadership can review and approve. This approach not only satisfies the regulatory requirement but also strengthens the organization's overall security posture against the threats that matter most to ePHI.