HIPAA Risk Analysis Guide

HIPAA risk analysis is a documented evaluation of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. It is required under Security Rule Section 164.308(a)(1)(ii)(A) and is the foundation of the entire Security Rule program.

The risk analysis serves two purposes:

1. Identifies risks to address: Without knowing your risks, you cannot prioritize controls
2. Documents reasonableness of decisions: When you choose addressable specifications or accept residual risk, the risk analysis is your justification

OCR enforcement consistently cites missing, inadequate, or stale risk analyses as Security Rule violations. The fines for risk analysis failures often exceed $1M for major covered entities.

Reference the HIPAA framework guide for the full Security Rule context.

HHS has published guidance on risk analysis methodology. While it does not prescribe a specific approach, it expects these steps:

1. Scope: Identify all locations and forms of ePHI in your environment
2. Data collection: Inventory information assets, current security measures, and threat sources
3. Threat identification: Identify potential threats: malicious actors, system failures, natural disasters, insider risks
4. Vulnerability identification: Identify vulnerabilities that could be exploited
5. Impact and likelihood determination: Assess the impact of threat-vulnerability combinations
6. Risk level determination: Combine impact and likelihood for risk score
7. Documentation: Produce the risk analysis report

NIST SP 800-30 (Guide for Conducting Risk Assessments) is the most common methodology reference. HITRUST CSF also provides a HIPAA-aligned risk methodology. Either works as long as you apply it consistently.

Scoping the risk analysis is where most programs fail. Common scope mistakes:

• Missing locations of ePHI: Email systems, backup systems, mobile devices, contractor laptops
• Missing forms of ePHI: Voicemail, fax, paper records that are scanned into electronic systems
• Missing data flows: PHI sent to vendors, transmitted via APIs, exported in reports
• Treating dev/test as out-of-scope: If production data ever flows to dev/test, dev/test is in scope

Build a comprehensive inventory:

• Production databases storing ePHI
• Backup systems and archives
• Email systems with PHI in attachments or content
• File storage systems
• Cloud services processing PHI
• Endpoints (laptops, mobile devices) with access to PHI
• Network paths PHI traverses
• Vendors and business associates handling PHI

Comprehensive scope is the foundation. Without it, the risk analysis has gaps that translate directly into Security Rule violations.

The risk analysis must be documented. A risk analysis that is not in writing does not satisfy the Security Rule. Documentation expectations:

• Methodology section: How the analysis was conducted
• Scope section: ePHI inventory, systems in scope, time period covered
• Threat and vulnerability inventory: Identified threats and vulnerabilities
• Risk register: Each risk with likelihood, impact, and overall rating
• Risk treatment decisions: For each risk, what you do about it (mitigate, transfer, accept)
• Approval and date: Senior official sign-off with date

Common documentation failures:

• Risk analysis dated 5 years ago with no updates
• Risk analysis that does not identify any actual risks (all rated low)
• Risk analysis that does not link to security controls or policies
• Risk analysis prepared by external consultant with no internal ownership

Make the risk analysis a living document. Update it formally at least annually and after significant changes.

The risk analysis is not a deliverable to file away. It drives the security program. Operationalize it by:

1. Linking to risk management: Each identified risk needs a treatment decision and tracked controls. The risk register becomes a working document.
2. Reviewing in security meetings: Top risks should be reviewed quarterly with security and IT leadership.
3. Updating after changes: New systems, new vendors, new threats, or significant incidents trigger risk register updates.
4. Annual refresh: Full risk analysis review at least annually with documented update.
5. Audit trail: Track risk analysis versions, approval dates, and significant changes over time.

If the OCR investigates, they will ask for your current risk analysis and evidence of how it drives your security program. A standalone document with no connection to operations does not satisfy this expectation.

Pair the HIPAA risk analysis with risk management programs from other frameworks (SOC 2, ISO 27001, HITRUST). The same identified risks can drive controls across multiple frameworks, reducing total documentation overhead.