White Paper · HIPAA · Risk Analysis

A HIPAA Risk Analysis That Holds Up in an OCR Investigation

A one-sentence requirement, and the gap between what it says and what an investigator expects. Scope, method, management, and evidence.

By Lincoln Square Law · 8-minute read

The risk analysis requirement sits at the center of HIPAA security enforcement. The requirement is short, a single sentence in the regulations, and the gap between what it says and what an investigator expects to see is where most organizations fail. OCR has made the point explicit by organizing an enforcement initiative around it. This paper explains what an accurate and thorough risk analysis contains, how to scope it, how to connect it to risk management, and what an organization should be able to produce if OCR asks for it.

What the rule requires

A covered entity or business associate must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information it holds (45 C.F.R. 164.308(a)(1)(ii)(A)). It must then implement security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level (45 C.F.R. 164.308(a)(1)(ii)(B)). Both are required implementation specifications. Neither can be treated as optional or addressed by a documented alternative.

The rule does not prescribe a method. It allows each organization to consider its size and complexity, technical capabilities, the costs of security measures, and the probability and criticality of potential risks (45 C.F.R. 164.306(b)). That flexibility applies to how the analysis is done, not to whether it is thorough.

The method HHS describes

HHS guidance on the risk analysis requirement, which draws on NIST Special Publication 800-30, describes the elements an analysis should include. They are: defining the scope to cover all ePHI, collecting data on where it is stored, received, maintained, or transmitted, identifying and documenting reasonably anticipated threats and vulnerabilities, assessing current security measures, determining the likelihood of each threat occurring and its potential impact, assigning a level of risk to each combination, and documenting the analysis and reviewing it periodically. An analysis that skips any of these steps is vulnerable.

Scope is where most analyses fail

The analysis must cover all ePHI, not just the electronic health record. In a typical practice, ePHI also lives in the practice management and billing systems, email, scanned documents, imaging and diagnostic devices, phones and tablets, backup media, cloud storage, patient portals and texting tools, and the systems of every business associate. Newer tools, such as AI scribes and scheduling assistants, add more.

Start with an inventory. List each system, device, and application that creates, receives, maintains, or transmits ePHI, and each vendor with access to it. Then trace how ePHI flows between them. An analysis that cannot show that inventory has no way to prove it was thorough.

Threats and vulnerabilities that fit the organization

Generic lists of threats produce generic analyses. The useful work is matching threats to the organization’s actual systems and practices. Ransomware is a threat everywhere, but whether it can reach the backups depends on how they are stored. Phishing is universal, but the vulnerability is whether email accounts use multi-factor authentication. A lost laptop is a minor event if the drive is encrypted and a reportable breach if it is not. Each threat and vulnerability pair should be written in terms specific enough that someone reading the analysis could verify the facts.

Likelihood, impact, and risk level

For each pair, assign a likelihood and an impact on a defined scale, and combine them into a risk level. The scale itself should be written down, so that a reader understands what high, medium, and low mean. The result is a ranked list that tells the organization where to spend first. Without that ranking, the risk management plan has no basis, and the organization cannot explain why it addressed some risks before others.

From analysis to management

The analysis is only half the requirement. The risk management plan must show, for each significant risk, the security measure chosen to reduce it, who owns it, when it will be done, and whether it was done. An analysis that sits in a file without action does not satisfy the rule, because the rule requires both. Update the plan as measures are completed, and record the residual risk the organization has accepted and why.

What an investigator will expect

In an investigation, expect to produce the current risk analysis and prior versions, with dates, the scope and method used, the inventory it relied on, the risk management plan and evidence of its implementation, and the policies that connect to it. An analysis dated years before the incident, or one that did not include the system that was breached, is the finding that turns an incident into an enforcement action.

Tools and outside help

HHS and the Office of the National Coordinator for Health IT publish a free Security Risk Assessment Tool designed for small and medium practices. It provides structure but not conclusions, and its output is only as good as the inventory and answers put into it. Outside assessors can bring expertise, but the organization remains responsible for the analysis. A report that describes a generic environment, or that no one inside the organization has read, will not help in an investigation. When counsel engages the assessor, some of the work may be protected by privilege, but the analysis the rule requires must still exist and be available.

Places analyses commonly miss

When reviewing a draft analysis, check whether it reaches these areas:

• Backups, including where they are stored and whether ransomware could reach them.
• Email and messaging, including personal devices used for work.
• Vendor systems, especially billing, IT management, and cloud services.
• Connected medical and imaging devices that store or transmit patient data.
• Accounts of departed staff and shared logins.
• New tools adopted since the last review, such as AI scribes or online scheduling.

Each gap found here belongs in the analysis with its own risk level.

How often

The current rule does not set a fixed interval. It requires periodic review and evaluation in response to environmental or operational changes (45 C.F.R. 164.308(a)(8), 164.316(b)(2)(iii)). In practice, that means updating the analysis whenever a significant system, location, vendor, or workflow changes, and at a regular interval in any event. The proposed Security Rule published in January 2025 would add more specific requirements for the content of the analysis and for maintaining the asset inventory, but it has not been finalized.

The enforcement context

In March 2026, OCR described its settlement with a software business associate, whose breach affected about 15 million people, as the twelfth enforcement action under its Risk Analysis Initiative. In April 2026, it announced four ransomware settlements in which the recurring violation was the failure to conduct an accurate and thorough risk analysis. The March 2026 settlement combined a payment with a three-year corrective action plan monitored by OCR. The cheaper course is to do the analysis properly before anything happens.

Who should own it

The security official should own the analysis, but it cannot be written by one person. Clinical leaders know which workflows depend on which systems, the IT lead or managed service provider knows how systems are configured, and practice leadership decides which risks the organization will accept. Record who contributed, have leadership sign and date the final version, and keep that record with the analysis.

Where to begin

For an organization without a current analysis, the first month is enough to build the inventory, gather the existing security measures, and draft the threat and vulnerability pairs. The second month is for ranking the risks and writing the management plan with owners and dates. From there, the work is implementation and upkeep. An organization that can show a dated, specific analysis and a plan it is executing is in a far stronger position than one with a polished report that describes someone else’s environment.