HIPAA Security Risk Analysis: A Practitioner's Guide

The short version

A HIPAA security risk analysis is an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information. It is required of covered entities and business associates by 45 CFR 164.308(a)(1)(ii)(A), and it is the foundation of the Security Rule: the risk-management, safeguard, and policy decisions that follow are all supposed to flow from it. Risk-analysis failures also recur across OCR enforcement actions and resolution agreements.

Almost every HIPAA Security Rule obligation traces back to one requirement: the risk analysis. The safeguards an organization implements, the level at which it implements them, and the decisions it documents are all supposed to be driven by an assessment of where electronic protected health information is actually at risk. When the Office for Civil Rights investigates a breach, the risk analysis is a central focus, and the absence of an accurate, thorough, enterprise-wide one recurs across its published enforcement actions and resolution agreements.

This guide covers what the risk analysis is, what the rule requires, what it must cover, how to conduct it, how it differs from a gap analysis, and where it fails.

What a HIPAA security risk analysis is

The requirement is at 45 CFR 164.308(a)(1)(ii)(A): conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information held by the organization. It is a required implementation specification, not an addressable one, which means there is no option to skip it. It applies to covered entities and to business associates alike.

The risk analysis is paired with risk management at 45 CFR 164.308(a)(1)(ii)(B), which requires implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. The analysis finds the risk; risk management acts on it. One without the other does not satisfy the rule.

What it must cover

OCR guidance and NIST SP 800-30 describe the elements of a compliant risk analysis. It has to reach all ePHI, wherever it lives.

Scope and data inventory. Identify all ePHI the organization creates, receives, maintains, or transmits, across all systems, media, and locations, including portable devices and cloud services.
Threats and vulnerabilities. Identify the reasonably anticipated threats to that ePHI and the vulnerabilities that a threat could exploit.
Current controls. Document the security measures already in place.
Likelihood and impact. Assess the likelihood that each threat-vulnerability pair occurs and the impact if it does.
Risk level. Determine the level of risk for each, as a basis for prioritizing remediation.

How to conduct a risk analysis

Step 1: Define the scope and inventory ePHI

Map every place ePHI lives and moves: servers, workstations, mobile devices, removable media, applications, and the systems of business associates. ePHI that is not inventoried cannot be protected, and an incomplete scope is the most common reason a risk analysis fails.

Step 2: Identify threats and vulnerabilities

For the assets in scope, identify reasonably anticipated threats, both technical and non-technical, and the vulnerabilities each could exploit.

Step 3: Assess current security measures

Document the controls already in place and how effective they are against the identified threats and vulnerabilities.

Step 4: Determine likelihood and impact

For each threat-vulnerability pair, judge how likely it is to occur and how serious the impact would be on the confidentiality, integrity, or availability of ePHI.

Step 5: Determine the level of risk

Combine likelihood and impact into a risk level for each item, and use it to prioritize. This is the output that feeds risk management.

Step 6: Document and maintain

Record the analysis and the basis for each conclusion, and update it. The risk analysis is an ongoing process, not a one-time project; it is revisited as systems, threats, and operations change.

Risk analysis versus gap analysis

This is the distinction OCR has called out in its guidance. A gap analysis is a partial check of whether specific controls are in place against a checklist. A risk analysis is a comprehensive assessment of the risks to all ePHI. A gap analysis can be a useful input, but it is not a risk analysis and does not satisfy 45 CFR 164.308(a)(1)(ii)(A). Substituting one for the other is a documented failure that recurs in OCR enforcement.

How often

The Security Rule does not set a fixed interval, and OCR treats the risk analysis as an ongoing process rather than an annual event. It should be reviewed periodically and updated in response to changes: new systems or applications, a move to the cloud, a merger, a new business associate, or a security incident. A risk analysis that predates a material change in the environment is treated as stale.

Where risk analyses fail

Incomplete scope. The analysis misses ePHI on mobile devices, in the cloud, or held by business associates.
Gap analysis in disguise. A control checklist is submitted as a risk analysis.
No risk levels. Threats and vulnerabilities are listed but never rated, so remediation cannot be prioritized.
One and done. The analysis is performed once and never updated as the environment changes.
No follow-through. Risks are identified but risk management under 164.308(a)(1)(ii)(B) never reduces them.

The risk analysis is the load-bearing requirement of the HIPAA Security Rule. Scope it to all ePHI, rate the risks, act on them through risk management, and keep it current. For the wider regime, see the HIPAA compliance guide and the HIPAA glossary; for the same risk discipline in other settings, see the GDPR DPIA guide and the BSA/AML risk assessment guide.

Primary sources

45 CFR 164.308(a)(1)(ii)(A): The HIPAA Security Rule risk analysis requirement.
45 CFR 164.308(a)(1)(ii)(B): The HIPAA Security Rule risk management requirement.
HHS Guidance on Risk Analysis Requirements under the HIPAA Security Rule: The Office for Civil Rights' guidance on what a compliant risk analysis covers.
NIST SP 800-66 Rev. 2 and NIST SP 800-30: Federal guidance on implementing the HIPAA Security Rule and conducting risk assessments.
HHS Office for Civil Rights, HIPAA enforcement and resolution agreements: Published OCR settlements and civil money penalties; risk-analysis failures recur across them.

Common questions

Is a HIPAA risk analysis required?

Yes. 45 CFR 164.308(a)(1)(ii)(A) requires a risk analysis as a required implementation specification of the Security Rule, for both covered entities and business associates. It is not optional, and it is the foundation the rest of the Security Rule's decisions are built on.

What is the difference between a HIPAA risk analysis and a gap analysis?

A gap analysis is a partial check of whether specific controls are in place against a checklist. A risk analysis is a comprehensive assessment of the risks and vulnerabilities to all ePHI. OCR has stated that a gap analysis is not a risk analysis and does not satisfy 45 CFR 164.308(a)(1)(ii)(A).

What must a HIPAA risk analysis cover?

It must reach all ePHI the organization creates, receives, maintains, or transmits, and identify the threats and vulnerabilities to that data, the current security measures, the likelihood and impact of each threat, and the resulting level of risk. An incomplete scope is the most common reason it fails.

How often should a HIPAA risk analysis be done?

The Security Rule sets no fixed interval, and OCR treats the risk analysis as an ongoing process. It should be reviewed periodically and updated when the environment changes, such as new systems, a move to the cloud, a merger, a new business associate, or a security incident.

Who must conduct a HIPAA risk analysis?

Both covered entities and business associates must conduct a risk analysis of the ePHI they hold. It is a required implementation specification under 45 CFR 164.308(a)(1)(ii)(A), so neither can skip it.