Hipaa Risk Analysis

HIPAA Risk Analysis — 45 CFR §164.308(a)(1)

Overview

The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the organization. Risk analysis under §164.308(a)(1)(ii)(A) is the foundational requirement of the Security Rule — it drives all subsequent safeguard decisions. OCR has identified failure to conduct a comprehensive, enterprise-wide risk analysis as the most common finding in breach investigations and compliance reviews. The risk analysis must be ongoing, not a one-time event, and must be updated whenever significant changes occur in the environment or in response to security incidents.

Legal Foundation

Regulatory Text

45 CFR §164.308(a)(1)(ii)(A) — Risk Analysis (Required):

"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."

45 CFR §164.308(a)(1)(ii)(B) — Risk Management (Required):

"Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a)."

OCR Guidance Documents

OCR published "Guidance on Risk Analysis Requirements under the HIPAA Security Rule" (July 14, 2010) establishing nine essential elements that an adequate risk analysis must address. This guidance, while not binding regulation, represents OCR's enforcement expectations and has been consistently applied in settlement agreements and corrective action plans.

OCR Nine Essential Elements

Element 1: Scope of the Analysis

The risk analysis must encompass all ePHI that the organization creates, receives, maintains, or transmits, in every form and location:

Asclepius Health Network Scope Inventory:

Element 2: Data Collection

Identify and document where ePHI is stored, received, maintained, or transmitted. Methods include:

• Automated discovery: Network scanning tools identifying systems communicating health data (HL7, FHIR, DICOM traffic analysis)
• Data flow mapping: Documenting how ePHI moves between systems, departments, and external parties
• Workforce interviews: Structured interviews with department managers, clinical informaticists, and IT staff
• System inventory review: Cross-referencing CMDB (Configuration Management Database) with ePHI classification tags
• Vendor assessment questionnaire responses: BA-reported ePHI handling practices
• Physical walkthroughs: Identifying workstations, printers, fax machines, and storage locations processing ePHI

Element 3: Identify and Document Potential Threats and Vulnerabilities

Threat Categories

Vulnerability Assessment Methods

• Penetration testing: Annual external and internal penetration test by independent third party
• Vulnerability scanning: Weekly automated scans of all network-connected assets (Qualys, Nessus, or equivalent)
• Configuration auditing: Quarterly review of system configurations against CIS benchmarks
• Social engineering testing: Semi-annual phishing simulations; annual physical penetration attempts
• Application security testing: SAST/DAST scanning of internally developed applications; third-party code review for critical systems
• Wireless security assessment: Quarterly rogue access point scanning; annual wireless penetration test

Element 4: Assess Current Security Measures

Document existing safeguards and their effectiveness:

Asclepius Health Network Current Controls Assessment (Sample):

Element 5: Determine the Likelihood of Threat Occurrence

Assign likelihood ratings based on threat capability, motivation, and existing controls:

Element 6: Determine the Potential Impact of Threat Occurrence

Assess the magnitude of harm if a threat exploits a vulnerability:

Element 7: Determine the Level of Risk

Risk is calculated as the product of likelihood and impact:

Risk Score = Likelihood × Impact

Asclepius Health Network Risk Register (Sample Entries):

Element 8: Finalize Documentation

The risk analysis must be documented in sufficient detail to demonstrate:

1. The scope covered all ePHI
2. Threats and vulnerabilities were comprehensively identified
3. Current security measures were evaluated
4. Likelihood and impact were assessed using a consistent methodology
5. Risk levels were determined
6. The analysis was conducted by qualified personnel

Required Documentation Components:

• Date of analysis and date range covered
• Personnel conducting the analysis (names, qualifications)
• Methodology description
• Complete asset inventory with ePHI classification
• Threat and vulnerability catalog
• Current controls inventory
• Risk scoring matrix and ratings
• Risk register with all identified risks
• Executive summary for leadership

Element 9: Periodic Review and Updates

The risk analysis is not a one-time activity. It must be updated:

• At least annually as a scheduled comprehensive review
• When new systems, applications, or technologies are implemented
• When significant changes to the operating environment occur (mergers, relocations, new facilities)
• After a security incident or breach
• When new threats are identified (new malware families, regulatory changes, threat intelligence alerts)
• When OCR or industry guidance identifies new risk areas

Risk Management and Mitigation Planning — §164.308(a)(1)(ii)(B)

For each risk above the organization's acceptable risk threshold, develop and implement a mitigation plan:

Mitigation Plan Template (Risk R-001: Ransomware):

Common OCR Findings

OCR consistently identifies the following deficiencies in risk analyses:

1. Not enterprise-wide: Analysis limited to EHR system only, excluding email, mobile devices, medical devices, and BA systems
2. Not updated: One-time analysis without periodic review or updates after significant changes
3. Not thorough: Failure to identify all ePHI assets, particularly shadow IT, personal devices, and cloud services
4. No documentation: Analysis conducted informally without written documentation
5. No risk management follow-through: Risks identified but no mitigation plans developed or implemented
6. Inadequate methodology: No structured approach to likelihood/impact determination; subjective risk ratings without defined criteria

Enforcement Actions for Risk Analysis Failures

Risk analysis deficiency is cited in the majority of OCR enforcement actions:

• Anthem Inc. (2018): $16 million — failed to conduct enterprise-wide risk analysis prior to breach affecting 78.8 million
• Premera Blue Cross (2020): $6.85 million — risk analysis failed to identify risks across the enterprise; did not assess all systems with ePHI
• Banner Health (2023): $1.25 million — risk analysis was not accurate and thorough; did not identify all risks to ePHI
• CHSPSC LLC (2020): $2.3 million — failed to conduct accurate risk analysis and implement risk management measures
• University of Massachusetts Amherst (2020): $650,000 — failure to conduct risk analysis of ePHI maintained by research programs
• Metro Community Provider Network (2017): $400,000 — risk analysis not conducted to sufficient depth

Integration Points

• hipaa-security-rule: Risk analysis drives implementation decisions for all technical, administrative, and physical safeguards
• hipaa-breach-notify: Post-breach risk analysis updates feed into breach risk assessment under §164.402
• hipaa-baa-management: Risk analysis must include ePHI held by or accessible to business associates
• hipaa-privacy-rule: Privacy risk assessments complement security risk analysis for comprehensive PHI protection