The HIPAA Security Rule risk analysis is the most commonly cited deficiency in OCR enforcement actions and HIPAA breach investigations. Despite being a legal requirement since 2005, a significant percentage of covered entities and business associates have either never conducted one, or have conducted something that does not satisfy the actual regulatory requirement. This post explains what the requirement actually involves.
The Regulatory Basis
The specific requirement is found at 45 CFR §164.308(a)(1)(ii)(A): covered entities and business associates must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [entity]."
This is a required implementation specification under the Administrative Safeguards section of the HIPAA Security Rule. It is not optional. It is not fulfilled by a policy statement. It requires documented analysis.
The OCR has provided specific guidance on what constitutes an adequate risk analysis through its Risk Analysis Guidance document and through settlement agreements where it has cited what was missing. Those enforcement actions are instructive: the OCR has consistently cited risk analyses that failed to cover all ePHI locations, that lacked documented likelihood and impact assessments, that were not updated when the environment changed, and that produced no evidence of results being used to implement security measures.
What a Compliant Risk Analysis Must Include
Based on the regulatory text and OCR guidance, a HIPAA-compliant risk analysis must include:
1. Scope of ePHI — An accurate determination of where electronic protected health information exists in your organization: servers, workstations, laptops, mobile devices, cloud services, portable media, backup systems, vendor systems, and data flows. This must be documented. "We think it's on the server" is not sufficient.
2. Threat identification — A systematic identification of potential threats to ePHI: ransomware, phishing, insider misuse, unauthorized access, device theft, system failure, natural disaster. The OCR expects identification of threats that are "reasonably anticipated" based on the organization's environment and the general threat landscape.
3. Vulnerability identification — Identification of vulnerabilities that could be exploited by those threats: misconfigured systems, lack of encryption, weak access controls, no patch management program, inadequate physical security, untrained staff. A vulnerability scan output is not a vulnerability identification — it is raw technical data that requires analysis and contextualization.
4. Assessment of current controls — An evaluation of the security controls already in place and their effectiveness at mitigating the identified risks. This includes technical controls (encryption, access controls, firewalls, MFA), administrative controls (policies, training, workforce sanctions), and physical controls (facility access, workstation security).
5. Likelihood and impact assessment — For each combination of threat, vulnerability, and asset, a determination of the likelihood that a threat will exploit the vulnerability and the impact to ePHI if it does. This produces a risk level (often expressed as a matrix: likelihood × impact = risk level).
6. Risk level determination — A documented determination of the level of risk to ePHI based on the likelihood and impact assessment.
7. Documentation — The entire process must be documented. The OCR will ask for the documentation in an investigation. If it is not documented, for enforcement purposes it may not have happened.
What a Risk Analysis Is NOT
The OCR has been explicit, through enforcement actions, about what does not satisfy the requirement:
- An antivirus software installation is not a risk analysis. - A firewall deployment is not a risk analysis. - A policy manual acknowledgment is not a risk analysis. - A vendor's "HIPAA compliance scan" is not a risk analysis (unless it actually meets the elements above, which most do not). - A questionnaire completed by internal staff about existing policies is not a risk analysis.
Several OCR settlements have specifically cited the finding that an organization "failed to conduct an accurate and thorough risk analysis" despite having some security measures in place. The presence of security measures is not the same as having documented the analysis that identified the risks those measures address.
How to Get One Done
A compliant HIPAA risk analysis requires:
- A qualified assessor who understands the HIPAA Security Rule requirements and the OCR's interpretation of those requirements (not just general cybersecurity) - Structured methodology for ePHI inventory, threat and vulnerability identification, and risk rating - Documentation standards that produce a deliverable the OCR would find credible - A process for using the risk analysis results to implement or update security measures
For Illinois healthcare organizations — physician practices, multispecialty groups, behavioral health providers, dental practices, hospital systems, and business associates — SecureNext provides formal HIPAA Security Rule risk analyses aligned to the OCR's Risk Analysis Guidance and conducted under a signed Business Associate Agreement.
Schedule a HIPAA compliance consultation to discuss your organization's risk analysis requirements and what a scoped engagement looks like.