The HIPAA Security Risk Analysis: What It Actually Requires

The business problem

The HIPAA Security Rule requires every covered entity and business associate to conduct an accurate and thorough assessment of the risks to electronic protected health information. Most organizations believe they have done this. Many have not, at least not in the way regulators, auditors, or plaintiffs' attorneys expect.

The gap usually isn't willful noncompliance. It's a category error. Leadership treats the risk analysis as a form to be completed once and kept on file, rather than as an ongoing risk-management process that should inform real decisions about budget, staffing, and technology.

Why it matters

The security risk analysis is widely reported, across breach investigations and enforcement actions, as the single most commonly cited HIPAA compliance failing. It is not that organizations skip the requirement entirely — it's that what they produce doesn't meet the bar of "accurate and thorough."

This matters beyond the risk of a regulatory finding. A weak risk analysis usually means the organization genuinely doesn't know where its ePHI lives, how it's exposed, or what would happen if a given system failed. The compliance exposure is a symptom; the underlying condition is a leadership team making decisions about risk without the information a real analysis is supposed to produce.

Signs the organization should pay attention now

• The risk analysis was purchased as a template or software output and never substantively reviewed by leadership
• It hasn't been meaningfully updated since a new system, vendor, EHR migration, or office location was added
• No one outside IT or compliance has seen it, and it has never informed a budget or staffing conversation
• It reads as a list of controls in place rather than an analysis of what could go wrong and how likely and damaging that would be
• Remediation items exist but have no owner, timeline, or tracking back to closure

What good looks like

A real risk analysis has four components that hold together as a single argument: scope (a genuine inventory of where ePHI is created, received, maintained, or transmitted), threat and vulnerability identification specific to the actual environment, likelihood and impact judged consistently, and documented remediation with named owners and real timelines.

The difference between this and a checklist exercise is not effort or page count — it's whether the output could actually change a decision.

Practical guidance

Ask to see the current risk analysis directly, not a summary of it. If it reads as a compliance artifact rather than a risk argument, that's the signal to act. Ask when it was last updated relative to the organization's last major system or vendor change — if those dates don't roughly line up, the analysis is already out of date. Treat the remediation plan the way you'd treat any other operational commitment: with an owner, a budget line if needed, and a status update on a recurring cadence.

My CISO Partner's perspective

We see the same pattern across organizations of very different sizes: the risk analysis exists, but it was built to satisfy an auditor rather than to inform leadership. Executive sponsorship closes that gap — when a risk analysis is scoped, reviewed, and acted on with real executive involvement, it stops being a compliance artifact and starts being what the regulation actually intended.

Where to go from here

If you're not confident your organization's HIPAA risk analysis would hold up to scrutiny — or if you've never actually seen the one on file — that's worth a direct conversation before it becomes someone else's finding.