Conducting a HIPAA Risk Assessment

Conducting a HIPAA Risk Assessment

The HIPAA Security Rule requires a risk analysis — but it deliberately doesn't mandate a specific methodology. OCR's own guidance states this directly: risk analysis methods will vary depending on an organization's size, complexity, and capabilities, and no single framework is required or endorsed. What's required is the substance — a thorough, accurate assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI, codified at §164.308(a)(1)(ii)(A) — not adherence to a particular numbered process.

This matters because OCR's current top enforcement priority, the Risk Analysis Initiative launched in 2024, is built entirely around this requirement. An inadequate or missing risk analysis is the single most frequently cited finding in OCR's recent resolution agreements — more common than any specific technical failure. Getting this right is worth more attention than almost anything else in a HIPAA compliance program right now.

A Sound Structure, Not a Mandated One

While no specific steps are required, most workable risk analysis processes — including the approach OCR's own guidance materials are adapted from (NIST SP 800-30) — cover the same ground:

Define scope. Identify every system, process, and third party that creates, receives, maintains, or transmits e-PHI — including external sources like vendors and consultants. A risk analysis that misses a vendor relationship or a shadow system isn't incomplete in a minor way; it's blind to risk in exactly the places OCR's enforcement cases keep finding gaps.

Identify threats and vulnerabilities. OCR's guidance explicitly separates these into technical vulnerabilities (unpatched systems, weak access controls) and non-technical vulnerabilities (ineffective or missing policies and procedures) — both categories matter, and non-technical gaps are easy to underweight relative to technical ones.

Assess current controls. Document what safeguards already exist and whether they're actually configured and used correctly — not just whether a control is nominally in place.

Determine risk levels. Evaluate likelihood and potential impact for each identified risk, typically using some form of risk-level matrix to make the prioritization consistent and defensible rather than ad hoc.

Develop a risk treatment plan. Decide and document what to do about each risk — mitigate, accept, transfer, or avoid — with the reasoning behind each decision, since OCR's investigators will ask not just what you decided but why.

Document and monitor on an ongoing basis. This is the step most often shortchanged. OCR's guidance is explicit that risk analysis should be a continuous process, not a one-time event — the Security Rule requires updating security measures "as needed," which means risk analysis needs to happen often enough to actually catch when something's changed.

A Free Starting Point: The SRA Tool

HHS's Office for Civil Rights, jointly with the Office of the National Coordinator for Health IT, publishes a free Security Risk Assessment (SRA) Tool specifically built to help small and mid-sized practices and business associates conduct a basic risk analysis under §164.308(a)(1). It's a reasonable starting point for smaller organizations, but it's not a substitute for a full risk management program at scale — larger organizations and business associates with more complex environments typically need it as a baseline rather than a complete solution.

Why This Specific Requirement Is Under the Most Scrutiny Right Now

OCR's 2025 settlements make the stakes concrete: of ten resolution agreements announced in the first five months of 2025 alone, nearly all cited an inadequate or missing risk analysis as a central finding, with penalties ranging from $25,000 to $3 million depending on severity. The pattern holds across very different organizations — small physician practices, hospital systems, IT service providers — which suggests this isn't a niche technical gap, it's a widespread, systemic one that OCR has deliberately decided to target.

Keeping the Risk Analysis Alive, Not Filed Away

A risk analysis completed once during initial compliance and never revisited is functionally indistinguishable from no risk analysis at all by the time an incident occurs years later — the systems, vendors, and threat landscape it assessed no longer match reality. Building risk analysis into a recurring cadence, rather than a one-time certification exercise, is also where this work starts to overlap meaningfully with ISO 27001's own ongoing risk assessment and treatment requirements — the same underlying discipline of identifying, scoring, and treating risk satisfies both, even though HIPAA's specific documentation requirements under the Security Rule remain distinct.

For what OCR specifically penalizes when this requirement is missing or weak, see Who Enforces HIPAA and How to Stay Compliant