What a HIPAA Security Risk Analysis actually is, and what OCR expects to see

Ask ten healthcare administrators whether their organization has a HIPAA Security Risk Analysis and most will say yes. Ask to see it, and what appears is often a vulnerability scan, a filled-in checklist, a policy binder, or a report from years ago with a new date on the cover. None of those is a risk analysis, and the difference matters because it is the first thing a federal investigator asks for.

What the rule actually requires

The requirement lives at 45 CFR 164.308(a)(1)(ii)(A). The language is brief: covered entities and business associates must "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."

Two features of that sentence deserve attention. First, it is a required implementation specification. The Security Rule divides its specifications into "required" and "addressable," and addressable ones allow an organization to document why an alternative is reasonable. Risk analysis is not addressable. Every regulated organization must do it, regardless of size.

Second, it says "accurate and thorough." OCR uses those two words deliberately in enforcement. An analysis that exists but is not accurate, or that covers only part of the organization, does not satisfy the requirement. Having a document is not the standard. Having a correct and complete one is.

A process, not a document

The most useful mental shift is to stop thinking of the risk analysis as a deliverable and start thinking of it as a decision-making exercise. The question it answers is: where is our patient information, what could go wrong, how likely is each thing, how bad would it be, and what are we going to do about it?

The report is simply the written record that the exercise took place, who participated, what they found, and what they decided. When OCR reviews a risk analysis, they are reading it to determine whether the underlying process was real. A polished report describing a process that did not happen is worse than a plain report describing one that did.

The nine elements OCR looks for

In 2010, OCR published guidance on the risk analysis requirement that remains the reference point. It identifies nine elements. An analysis that skips any of them is exposed.

1. Scope. The analysis must cover all ePHI the organization creates, receives, maintains, or transmits, in every form and every location. Not just the EHR. Email, billing systems, file servers, backups, laptops, phones, scanners, cloud services, and paper-to-digital workflows all count.
2. Data collection. You must identify where ePHI actually lives and how it moves. This means an inventory, and it means talking to the people who handle the data, because the official system diagram rarely matches what staff actually do.
3. Identify and document threats and vulnerabilities. Threats are things that could cause harm: a phishing attack, a lost laptop, a disgruntled employee, a flood, a vendor breach. Vulnerabilities are weaknesses those threats could exploit: no encryption on the laptop, no MFA on remote access, no offsite backup.
4. Assess current security measures. What controls are already in place, and are they actually working? A policy that exists on paper but is not followed does not count as a control.
5. Determine likelihood. For each threat and vulnerability pair, how probable is it? This is a judgment, but it must be a documented one with reasoning.
6. Determine potential impact. If it happened, how bad would it be? Number of records, clinical consequences, financial cost, regulatory exposure.
7. Determine level of risk. Likelihood and impact combine into a risk level. This is what lets you prioritize, and prioritization is the entire point.
8. Finalize documentation. Write it down, in a form someone else could read and understand. The Security Rule does not prescribe a format, but it does require the documentation to exist and be retained.
9. Periodic review and updates. The analysis is not a one-time event. It must be revisited as the environment changes and as new threats emerge.

The scope mistake

The single most common failure is scope. Organizations analyze the EHR, because the EHR is where they think of patient data living, and stop there.

But ePHI is everywhere. It is in the practice management system. It is in email, both sent and received. It is in the shared drive where someone saved an export. It is on the laptop a provider takes home. It is in the copier's internal hard drive. It is in the cloud fax service, the patient portal, the telehealth platform, the backup tapes in a drawer, and the phone that receives text messages from patients.

OCR's position is unambiguous: the analysis covers all of it. When a breach occurs through a system that was never in the analysis, the organization has two problems instead of one.

What enforcement looks like

Read through OCR's published settlements and resolution agreements over the past decade and a pattern is hard to miss. The specific incident varies, a stolen laptop, a ransomware attack, a misconfigured server, a business associate breach. But the finding that appears in the majority of them is the same: the organization failed to conduct an accurate and thorough risk analysis.

That finding matters because it changes the character of the violation. An organization that suffered a breach despite a real risk analysis and a real remediation plan has a defensible story: we assessed the risk, we made reasonable decisions, something got through anyway. An organization that never analyzed the risk has no such story. The breach becomes evidence of a systemic failure rather than a single bad day.

It also matters for MIPS. Clinicians in the Promoting Interoperability category attest annually that they conducted a risk analysis. An attestation without an analysis behind it is a false statement to CMS, which carries its own consequences beyond HIPAA.

What a risk analysis is not

A few things commonly get mistaken for one:

• A vulnerability scan. Useful input. Covers technical weaknesses only. Says nothing about administrative or physical safeguards, workforce behavior, or business associates.
• A compliance checklist or gap assessment. Tells you which Security Rule provisions you have and have not addressed. Does not assess the actual risk to your actual data. OCR has said explicitly that a gap assessment is not a substitute.
• A policy set. Policies are controls. The risk analysis is what tells you which controls you need and whether the ones you have are adequate.
• Your EHR vendor's security documentation. Describes their product. Says nothing about your network, your staff, or the other twenty places your data goes.
• Last year's analysis with a new date. Environments change. Threats change. A recycled analysis is neither accurate nor thorough.

Doing it well

A good risk analysis has a few recognizable qualities. It is specific to the organization, naming real systems and real workflows rather than generic categories. It is honest, documenting the uncomfortable findings alongside the reassuring ones. It is prioritized, so that the reader knows what matters most. And it leads somewhere, into a risk management plan with owners, dates, and follow-through.

Whether an organization does this internally, with a tool, or with outside help is a question of staffing and complexity, not of validity. Small practices produce defensible analyses using the free HHS tool when someone with real knowledge of the environment takes it seriously. Large organizations with dedicated security teams sometimes produce analyses that fail because they were scoped too narrowly. The method matters less than the rigor.

If your current analysis would not survive the practical test above, the right time to fix it is before anyone asks to see it.