HIPAA Security Risk Analysis: Required Content and OCR Audit Standards
Last reviewed · By Chad Griffith
The HIPAA Security Rule at 45 CFR 164.308(a)(1)(ii)(A) requires every covered entity and business associate to '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 covered entity or business associate.' The risk analysis is the foundational HIPAA Security compliance activity — every other Security Rule safeguard is supposed to be reasonably and appropriately implemented based on what the risk analysis identifies. Yet HHS Office for Civil Rights audits and breach investigations consistently identify inadequate or missing risk analyses as the most common HIPAA Security Rule deficiency. OCR has imposed multi-million-dollar penalties for risk analysis failures even when no breach occurred.
What the Risk Analysis Must Cover
Per 45 CFR 164.308(a)(1)(ii)(A), the risk analysis must address risks to all electronic Protected Health Information (ePHI) the entity creates, receives, maintains, or transmits. This includes: ePHI in production systems (EHR, billing, scheduling), ePHI in development and test systems if real data is used, ePHI on mobile devices and remote work environments, ePHI with business associates (the BA must conduct their own risk analysis but the covered entity must assess BA risk), ePHI in cloud-hosted services, and ePHI in physical media (backup tapes, USB drives, paper printouts of ePHI).
Common scope failures: focusing only on the EHR while missing ancillary systems (medical imaging archives, lab interfaces, claim submission systems); excluding remote work or mobile devices; failing to address ePHI created by IoT medical devices; and excluding business associate risk. OCR investigators routinely test scope by asking 'where else does ePHI exist in your organization?' — answers that don't match the risk analysis scope are an immediate finding.
Threat Identification
HHS-provided guidance (NIST SP 800-66 r2 and the HHS Risk Analysis Guidance) calls for identification of natural threats (floods, earthquakes, fires, severe weather), human threats (intentional like external hackers, malicious insiders; unintentional like accidental file deletion, improper disposal, lost devices), and environmental threats (power failure, HVAC failure, structural failure of facility). The 'human threats' category is consistently the largest source of actual breach incidents reported to OCR — with social engineering, ransomware, and insider misuse being the predominant categories in HHS Annual Reports to Congress.
Threat identification must be documented per source. Common documentation: a threat catalog spreadsheet listing each identified threat, its source category, the systems or data potentially affected, and a likelihood rating. Generic threat lists (e.g., 'cyberattacks') are insufficient — threats must be specific enough to drive identification of vulnerabilities and the appropriate safeguards.
Vulnerability Assessment
For each identified threat, the risk analysis must identify vulnerabilities in the entity's environment that the threat could exploit. Vulnerabilities span technical (unpatched systems, weak passwords, missing encryption, lack of multi-factor authentication, missing logging), administrative (lack of policies, missing training, weak access management procedures, BAAs not in place), and physical (unsecured server rooms, lost-laptop incidents, unsecured paper printouts of ePHI).
Vulnerability identification typically uses a combination of: vulnerability scanning of technical systems (Tenable, Qualys, Rapid7); penetration testing engagements; control gap analysis against the NIST SP 800-66 framework or NIST SP 800-53 controls; and self-assessment using OCR's Security Risk Assessment Tool (free at HealthIT.gov). Vulnerability findings must be tied to specific threats — generic vulnerability lists without threat-vulnerability mapping fail OCR audit standards.
Risk Likelihood and Impact Rating
Each threat-vulnerability pair must be rated for likelihood and impact, producing a risk score that drives prioritization of risk management efforts. Likelihood ratings typically use a 5-level scale (very low, low, moderate, high, very high) based on threat frequency and vulnerability exploitability. Impact ratings consider: scale of ePHI exposure (number of individuals), sensitivity of ePHI types affected, reputational and legal consequences, and operational disruption.
Risk scoring methodologies vary. NIST SP 800-66 r2 illustrates a 5x5 matrix producing risk levels from very low to very high. Many organizations use simpler 3x3 matrices. The specific methodology matters less than consistent application — OCR investigators look for systematic risk rating across all identified threat-vulnerability pairs, not selective rating of high-profile risks.
Risk Management Plan
The risk analysis is paired with a Risk Management Plan under 45 CFR 164.308(a)(1)(ii)(B) that documents the safeguards the entity will implement to reduce identified risks to a reasonable and appropriate level. For each risk above the entity's risk tolerance threshold, the plan must specify: the safeguard or control that will address the risk, the responsible party, the implementation timeline, and the projected residual risk after implementation.
The risk management plan is a living document. As new threats emerge (new ransomware techniques, new insider threat patterns) and new vulnerabilities are identified (newly disclosed CVEs, newly observed misconfigurations), both the risk analysis and risk management plan must be updated. NIST recommends formal risk analysis update at least annually plus event-driven updates. OCR investigates frequency of update during audits — risk analyses dated more than 18 months prior to investigation are routinely cited.
OCR Audit Findings and Penalty Examples
Inadequate risk analysis is consistently the most-cited HIPAA Security Rule violation in HHS Annual Reports to Congress. Penalty examples (publicly resolved enforcement actions): Anthem's 2018 $16 million settlement included findings of inadequate risk analysis among the deficiencies leading to the breach of 78.8 million records. Touchstone Medical Imaging's 2019 $3 million settlement included risk analysis failures. The 2024 Lafourche Medical Group $480,000 settlement specifically focused on risk analysis inadequacy — making the case-in-point that OCR penalizes failure to conduct adequate risk analyses even without a breach.
Penalty tiers under 2026 inflation-adjusted amounts: Tier 1 (no knowledge) — $137 to $68,928 per violation; Tier 2 (reasonable cause) — $1,379 to $68,928 per violation; Tier 3 (willful neglect, corrected) — $13,785 to $68,928 per violation; Tier 4 (willful neglect, not corrected) — $68,928 to $2,067,813 per violation. Annual cap per identical provision: $2,067,813. Risk analysis findings are typically cited as Tier 2 or Tier 3 depending on whether the entity made any prior attempt at risk analysis.
Frequently Asked Questions
How often must a HIPAA risk analysis be performed?
HIPAA does not specify a fixed frequency, but NIST SP 800-66 r2 and OCR guidance recommend at least annual review plus event-driven updates (after significant changes to systems, after a breach incident, after new technology adoption, after regulatory changes). Risk analyses dated more than 18 months prior to OCR investigation are routinely cited as inadequate due to staleness.
Can business associates rely on the covered entity's risk analysis?
No. Business associates are independently required to conduct risk analyses for the ePHI they handle on behalf of covered entities. The CE and BA risk analyses serve different scopes — the BA's analysis covers the BA's environment and systems. BAAs may incorporate language about coordinated risk management, but each party's risk analysis is its own legal compliance obligation.
Is the OCR Security Risk Assessment Tool sufficient for compliance?
The Security Risk Assessment Tool (SRA Tool) provided free at HealthIT.gov is a useful starting point for small to mid-sized practices. It walks through HIPAA Security Rule requirements as a structured questionnaire. However, the SRA Tool is not a complete risk analysis methodology — using only the SRA Tool's output as the risk analysis has been cited as inadequate in OCR investigations of larger organizations. The tool should be supplemented with detailed threat identification, vulnerability assessment, and risk rating documentation.
Does encryption requirement come from the risk analysis?
Yes. HIPAA does not mandate encryption explicitly — encryption is an 'addressable' implementation specification under 45 CFR 164.312(a)(2)(iv) (transmission) and 164.312(e)(2)(ii) (transmission). 'Addressable' means the entity must implement the safeguard if reasonable and appropriate, OR document why an equivalent measure is more appropriate, OR document why no safeguard is reasonable. The risk analysis determines whether encryption is reasonable and appropriate. In practice, virtually every modern environment has risks that make encryption reasonable, and OCR has cited entities that failed to implement encryption without documenting an adequate alternative.
Authoritative sources