If you look at OCR enforcement actions over the past decade, one finding appears more than any other: inadequate risk analysis, or no risk analysis at all. Not encryption failures. Not BAA violations. Risk analysis.
The reason is straightforward: 45 CFR §164.308(a)(1)(ii)(A) explicitly 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 electronic protected health information." It is required, not addressable.
Most organizations have policies about security. Many have technical controls. Far fewer have documentation proving they ever sat down and systematically analyzed where their ePHI is, what could happen to it, and what they're doing about it.
What a Risk Analysis Actually Is
A HIPAA risk analysis is not a risk assessment in the generic security sense. It's a specific, documented process that HHS defines through official guidance. The 2010 HHS guidance document on risk analysis (still current) identifies nine required elements. If your risk analysis doesn't address all nine, it's incomplete — regardless of how long it is or how professional it looks.
Element 1: Scope
Define what you're analyzing. Scope covers all ePHI your organization creates, receives, maintains, or transmits. This includes:
- Data in your EHR and practice management systems
- ePHI on workstations and servers
- Data on portable devices (laptops, tablets, phones, USB drives)
- ePHI in cloud storage and backup systems
- Paper records that have been scanned and stored digitally
- ePHI sent and received via secure messaging or email
The scope definition has to be accurate. An analysis that covers your EHR but ignores the shared drive where staff save patient scheduling spreadsheets isn't complete.
Element 2: Data Collection
Before you can assess risk, you need to know where your ePHI lives. This is an inventory exercise:
- What systems store or process ePHI?
- Where is ePHI transmitted (internal and external)?
- Who has access to each system?
- What types of PHI (clinical, financial, demographic) does each system hold?
This is often the most time-consuming part of a real risk analysis. Organizations regularly discover ePHI in places they didn't expect — email attachments, legacy systems, staff personal devices.
Element 3: Identify Potential Threats and Vulnerabilities
Threats are the things that could harm your ePHI. Vulnerabilities are the weaknesses that could be exploited. Both intentional and unintentional threats must be considered:
Intentional: external hackers, ransomware, insider threats, theft of portable devices, social engineering
Unintentional: accidental disclosure, user error, software bugs, natural disasters, hardware failure
The threat/vulnerability analysis needs to be specific to your environment. Generic threat lists don't satisfy this requirement if they don't reflect what's actually relevant to your organization's systems and operations.
Element 4: Assess Current Security Measures
Document what controls you already have in place and evaluate their effectiveness. This includes technical controls (encryption, MFA, audit logging), administrative controls (policies, training, access reviews), and physical controls (office security, workstation placement, visitor management).
The point of this element is to establish a baseline — what protection you currently have — so you can assess whether it's adequate for the threats you've identified.
Element 5: Determine Likelihood of Threat Occurrence
For each threat/vulnerability combination, assess how likely it is that the threat will actually exploit the vulnerability, given your current controls. This doesn't require precision — high/medium/low or a numeric scale both satisfy the requirement. What it requires is documented reasoning.
"We have no firewall" and "we have a configured, monitored firewall" represent very different likelihood assessments for network-based attacks. The current controls (Element 4) directly inform this assessment.
Element 6: Determine Potential Impact
If the threat does occur, what are the consequences? Consider:
- Financial impact (breach response costs, regulatory penalties, litigation)
- Reputational impact (patients, referral sources, the community)
- Operational impact (systems offline, staff unable to work, care disruption)
- Regulatory impact (OCR investigation, state health department notification)
Impact is also rated — high/medium/low or equivalent — with documented reasoning.
Element 7: Determine Risk Level
Combine likelihood (Element 5) and impact (Element 6) to determine the overall risk level for each identified risk. A common approach: a 3x3 or 5x5 risk matrix where likelihood and impact intersect. High likelihood + high impact = high risk requiring immediate treatment.
This produces the prioritized list of risks that drives your risk treatment plan.
Element 8: Finalize Documentation
The risk analysis must be documented and retained for a minimum of 6 years from the date of creation or the date it was last in effect, whichever is later.
What the documentation needs to show: your methodology, the data you collected, your threat/vulnerability analysis, your risk ratings, and your reasoning. A completed spreadsheet with named risks and ratings satisfies this if the methodology is documented. A PDF from a vendor tool satisfies this if the underlying analysis is sound.
What doesn't satisfy it: a policy that says "we conduct annual risk analyses" without documentation of an actual analysis ever being performed.
Element 9: Periodic Review and Updates
A risk analysis isn't a one-time project. The Security Rule requires that you update your risk analysis in response to environmental or operational changes. Common triggers:
- Adding new systems or migrating to the cloud
- Acquiring new practice locations
- Implementing new workflows that involve ePHI
- Experiencing a security incident
- Workforce changes that affect access to ePHI
- Changes in the threat environment (new ransomware variants targeting healthcare)
Annual review is a reasonable baseline. For practices in periods of rapid change, more frequent updates may be appropriate.
Common Failures
Scope limited to the EHR: The EHR is one system. ePHI often exists in billing systems, document management systems, scheduling applications, email, and shared drives. An analysis that addresses only the EHR leaves gaps.
Using a vendor's risk assessment as your risk analysis: Some EHR and software vendors offer "risk assessments" of their own products. This tells you whether your software is configured securely — it doesn't tell you whether your organization's overall handling of ePHI is appropriate. It's one input to your risk analysis, not the risk analysis itself.
Completing the analysis but not updating it: OCR has cited organizations for having a risk analysis that was current in year one but never updated through subsequent years when the organization grew, changed systems, or experienced incidents.
No connection between the risk analysis and actual controls: Your risk treatment plan should flow from your risk analysis. If your risk analysis identifies unencrypted portable devices as a high risk and you haven't implemented encryption, the analysis and your actual security posture tell inconsistent stories.
The Stakes
OCR's HIPAA enforcement actions since 2019 consistently include risk analysis findings. Even small practices have faced settlements:
- Green Ridge Behavioral Health (2023): $40,000 — risk analysis and risk management failures
- Dental practice settlements (2019-2023): Multiple practices with 1,000-5,000 patient records settled for $10,000-$100,000
The size of the settlement often reflects the size of the organization, not just the severity of the violation. Small practices are not exempt from OCR scrutiny, and missing a required element of the Security Rule is not a technicality.
SOURCES
- 45 CFR §164.308(a)(1) — Security Management Process: ecfr.gov
- HHS, "Guidance on Risk Analysis Requirements under the HIPAA Security Rule" (2010): hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
- HHS Security Risk Assessment (SRA) Tool (free download): healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool
- OCR HIPAA Enforcement — Resolution Agreements: hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html
Need help conducting a HIPAA risk analysis that satisfies OCR requirements? Schedule a consultation to talk through what a complete analysis looks like for your organization.
