HIPAA risk analysis vs risk assessment, what OCR actually scores

The HHS Office for Civil Rights settlement page contains a repeating phrase. Variations of “failure to conduct an accurate and thorough risk analysis” appear in resolutions covering small medical practices, multi-state health systems, business associates and behavioral health groups. It is the single most-cited Security Rule deficiency in OCR’s published enforcement history. The settlements range from low five figures to seven figures depending on scope.

The reason the same phrase keeps appearing: most covered entities and business associates believe they have done a risk analysis. What they have usually done is a different thing, a general risk assessment or a vendor-template checklist, that does not satisfy the regulatory requirement.

This post covers what the formal Security Rule risk analysis is, why OCR draws the distinction strictly and how to execute one that actually closes the obligation.

What the regulation says

The HIPAA Security Rule includes one mandatory implementation specification at 45 CFR 164.308(a)(1)(ii)(A):

“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.”

This is the Risk Analysis. It is required, not addressable. Without it, the Security Rule’s Risk Management standard (the immediate follow-on at 164.308(a)(1)(ii)(B)) has nothing to manage from.

OCR clarified the scope expectations in the 2010 Final Guidance on Risk Analysis Requirements under the HIPAA Security Rule. The guidance is still the operative reference. It specifies that a compliant risk analysis covers:

• Scope of all ePHI created, received, maintained or transmitted, across the entire entity
• Identification of threats and vulnerabilities
• Assessment of current security measures
• Determination of likelihood and impact
• Determination of the level of risk
• Documentation
• Periodic review and update

A vendor scorecard, an MSP-template checklist or a generic “security assessment” delivers none of those elements end-to-end. That is why OCR keeps citing the failure even at practices that paid for some flavor of assessment.

Risk analysis vs risk assessment

The word “assessment” is used both broadly and narrowly in HIPAA writing, which creates confusion. The clarifying distinction:

• Risk Analysis (the regulatory term): the specific, required Security Rule artifact described above. A documented, environment-specific analysis of threats, vulnerabilities, current controls, likelihood and impact across all ePHI. Output is a written report that drives the Risk Management Plan.

• Risk Assessment (general usage): a broader category that includes many related but distinct artifacts. Examples: a Breach Risk Assessment to determine whether an incident qualifies as a breach under the Breach Notification Rule, a Vendor Risk Assessment for a new business associate, a Penetration Test Risk Assessment, an IT security posture assessment.

A covered entity can perform many risk assessments throughout the year. None of them satisfies the Risk Analysis requirement unless the artifact specifically meets the Security Rule scope and methodology. The OCR pattern is consistent: practices show OCR a stack of “risk assessments” and OCR cites them for not having the Risk Analysis.

What OCR actually looks at

When OCR opens a Security Rule investigation, the document request usually includes the Risk Analysis as one of the first artifacts. From published settlement findings, the recurring deficiencies:

• Scope gaps: the analysis covers the EHR but not email, or covers headquarters but not satellite locations, or covers desktops but not mobile devices and personal devices.
• Generic threat lists: the analysis lists threats copied from a template without environment-specific tailoring. OCR’s published example: a small practice’s risk analysis listing “earthquakes” as a primary threat in a geography where earthquakes are not a meaningful concern, suggesting copy-paste from a generic template.
• No documented current controls assessment: the analysis identifies risks but does not document what controls are currently in place against each.
• No likelihood/impact methodology: ratings appear without explanation of the scoring scheme.
• Stale: the most recent analysis is 3+ years old with no documented review.
• No linkage to the Risk Management Plan: the analysis identifies risks but the practice cannot show what was done about them.

A risk analysis that addresses all of those points in writing is the artifact OCR is looking for. Length is not the metric; specificity is.

The methodology

A practical methodology that aligns with the 2010 OCR Guidance, scoped for a small to mid-size covered entity:

ePHI inventory

Every system that creates, receives, maintains or transmits ePHI. The full list:

• EHR (cloud or on-premise)
• Practice management or billing system
• Patient portal
• Email accounts
• Workstations and mobile devices used by clinical and administrative staff
• File and document storage (network shares, OneDrive, Google Drive, SharePoint)
• Backup systems including cloud backup
• Imaging systems, lab interface systems, dictation
• Telehealth platform
• Third-party SaaS handling any of the above

Each system gets a row: name, vendor, data types, who has access, where it lives (cloud region or physical location), how it connects to other systems. Output is a table the rest of the analysis references.

Threat and vulnerability identification

For each system in scope, list the threats and vulnerabilities specific to the environment. Threats are sources of harm (people, things, events): ransomware actor, phishing campaign, insider misuse, lost or stolen device, vendor compromise, accidental disclosure, natural events that apply to the geography. Vulnerabilities are weaknesses in the environment: missing MFA, unpatched systems, weak access controls, shared accounts, insufficient logging, no backup encryption.

A defensible analysis pairs threats and vulnerabilities. “Ransomware exploiting unpatched workstations” is a pair. “Ransomware” alone is not. OCR’s deficiency citations often point at this gap.

Current controls assessment

For each threat-vulnerability pair, document the controls currently in place. Examples: “MFA enforced on EHR and email; not enforced on practice management system.” “Daily backup with offsite copy; backup encryption not enabled.” “Endpoint AV but no EDR.”

Honest assessment is the point. A controls assessment that overstates current state produces a risk analysis that understates risk and drives a risk management plan that does not actually reduce risk.

Likelihood and impact rating

Rate each risk on a documented scale. A 3x3 (Low/Medium/High) or 5x5 numeric scale is common. The scale itself goes in the report so reviewers can interpret the ratings. Likelihood × impact produces an overall risk score that drives prioritization.

Documentation and prioritization

The output is a written report. For small practices, 15-30 pages plus appendices is typical. The report covers scope, methodology, the inventory, the threat-vulnerability pairs, the controls assessment, the ratings and the prioritized findings. The findings feed directly into the Risk Management Plan, which is the next regulatory obligation.

Cadence

OCR has not specified a frequency. The enforcement record makes the practical answer clear: stale risk analyses get cited. Annual full refresh is the operational baseline. Any material change to the environment triggers an interim refresh: new EHR, new location, new business associate, expanded service line, security incident.

The scope disclaimer

Atticus Rowan’s HIPAA practice focuses on the Security Rule and the Breach Notification Rule. The Privacy Rule, which governs uses and disclosures of PHI rather than security safeguards, is outside our scope; that work belongs with HIPAA-specialized legal counsel or a HIPAA privacy consultant. The risk analysis described above is a Security Rule artifact specifically and is the work we own end-to-end.

Where this fits

The risk analysis is the foundation of the Security Rule program. Everything else (the technical safeguards, the policies, the training, the BAAs, the incident response plan) flows from the findings the analysis surfaces. Our Medical Practice HIPAA 60-90 day post covers the broader Security Rule implementation arc. Our HIPAA Readiness Guide walks through the full Administrative, Physical and Technical Safeguards set.

If your practice has not had a documented Security Rule risk analysis in the past 12 months, or has a vendor-template assessment that you suspect would not survive OCR review, schedule a discovery call. We can scope the boundary, run the analysis and produce the artifact the Security Rule actually requires.