HIPAA Security Risk Analysis

The HIPAA Security Risk Analysis is the most frequently cited violation in HIPAA enforcement actions. Year after year, when the Office for Civil Rights publishes its resolution agreements and civil money penalty findings, the same deficiency appears at the top of the list: an organization either never completed a risk analysis, completed one that was too narrow in scope, or completed one and then never updated it.

That is not a coincidence. The risk analysis sits at the foundation of the entire HIPAA Security Rule framework. Everything else — your policies, your technical controls, your workforce training — is supposed to be driven by what your risk analysis identifies. Without it, your compliance program has no anchor.

This article explains what a compliant risk analysis actually requires, who must complete one, how often it needs to be done, and what the common mistakes are that put organizations at risk during an OCR investigation.

What Is a HIPAA Security Risk Analysis?

The Security Risk Analysis is required under 45 CFR 164.308(a)(1)(ii)(A), which falls under the Administrative Safeguards section of the HIPAA Security Rule. The regulation requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) they create, receive, maintain, or transmit.

In plain terms, the risk analysis is a structured evaluation of where your ePHI lives, what threats could compromise it, how vulnerable you are to those threats, and what the resulting risk level is. It is not a checklist. It is not a vendor questionnaire. It is a documented, systematic analysis that your organization conducts and maintains over time.

OCR has been explicit in its guidance that the risk analysis must be enterprise-wide in scope. It cannot be limited to one system, one department, or one location. If ePHI touches it, that system or process needs to be evaluated.

Who Is Required to Complete a Risk Analysis?

Both covered entities and business associates are required to conduct a Security Risk Analysis. This is a point that catches many organizations off guard, particularly technology companies and service providers that work with healthcare clients.

Covered entities include:

• Healthcare providers that transmit health information electronically (physician practices, hospitals, dental offices, behavioral health providers, home health agencies)
• Health plans, including employer-sponsored health plans
• Healthcare clearinghouses

Business associates include:

• Medical billing companies and revenue cycle management firms
• IT service providers and managed service providers with access to ePHI
• SaaS vendors whose platforms store, process, or transmit ePHI
• Cloud service providers hosting ePHI
• Consultants and contractors with access to patient information
• Any organization that creates, receives, maintains, or transmits ePHI on behalf of a covered entity

If your organization handles ePHI in any capacity, the risk analysis requirement applies to you. Signing a Business Associate Agreement does not transfer this obligation away. Each party in the chain is responsible for conducting its own analysis.

How Often Does a Risk Analysis Need to Be Done?

HIPAA does not specify a fixed interval for risk analysis updates. OCR guidance and industry practice have converged on an annual review cycle as the reasonable standard, but the regulation uses language focused on keeping the analysis current rather than mandating a calendar-year schedule.

Practically, this means your risk analysis should be reviewed and updated whenever there is a change that affects your ePHI environment. Triggers that warrant an update include:

• Implementing a new electronic health record (EHR) system or practice management software
• Adding a new cloud service or third-party vendor with access to ePHI
• Opening a new office location or acquiring another practice
• Moving to remote or hybrid work arrangements
• A security incident or breach, even one that did not result in a reportable disclosure
• Major changes to your network infrastructure or security controls
• A merger, acquisition, or significant organizational change

The practical guidance is to treat your risk analysis as a living document rather than a one-time project. Organizations that complete a thorough initial analysis and then update it systematically are in a far stronger position than those that rush to produce documentation under the pressure of an OCR inquiry.

What a Compliant Risk Analysis Must Include

OCR has published detailed guidance on what a compliant risk analysis must cover. The agency references NIST SP 800-30 as a recommended framework, though organizations are not required to use that specific methodology. What OCR does require is that the analysis be accurate, thorough, and well-documented.

A compliant risk analysis covers five core areas:

1. ePHI Scope and Asset Inventory

Identify all the ePHI your organization creates, receives, maintains, or transmits. Document every system, application, device, and location where ePHI exists. This includes servers, workstations, mobile devices, cloud storage, email systems, backup media, and any third-party platforms. Organizations frequently underestimate the scope of their ePHI environment, which is why OCR requires the analysis to be enterprise-wide.

2. Threat Identification

Identify the reasonably anticipated threats to your ePHI. These include both human threats (malicious actors, unauthorized access, workforce errors) and environmental threats (natural disasters, power failures, hardware failures). The analysis should be specific to your environment, not a generic list copied from a template.

3. Vulnerability Identification

For each threat, identify the vulnerabilities in your environment that could allow that threat to materialize. A vulnerability might be a lack of encryption on mobile devices, weak password policies, unpatched software, insufficient access controls, or inadequate physical security at a facility. Document the weaknesses, not just the threats.

4. Current Control Assessment

Document the security measures already in place and evaluate their effectiveness in addressing identified vulnerabilities. This step is important because it gives you credit for what you have already implemented and helps identify gaps where additional controls are needed.

5. Likelihood, Impact, and Risk Level Determination

For each threat-vulnerability pair, assign a likelihood rating (how probable is it that this threat exploits this vulnerability?) and an impact rating (what would the consequences be if it did?). Combining those two ratings produces a risk level. The output is a prioritized list of risks that drives your Risk Management Plan, which is a separate but related requirement under 45 CFR 164.308(a)(1)(ii)(B).

Common Mistakes That Lead to HIPAA Penalties

OCR enforcement actions involving risk analysis failures tend to cluster around a few recurring patterns. Understanding them is useful because they illustrate what OCR actually looks for when it audits an organization.

Scope that is too narrow. Many organizations conduct a risk analysis that covers their primary EHR system but ignores ancillary systems where ePHI also lives. A medical practice might assess its practice management software but overlook the scheduling platform, the patient portal, the billing service, and the file server where scanned documents are stored. OCR has penalized organizations specifically for incomplete scope.

A risk analysis that was never updated. An organization that completed a thorough risk analysis five years ago and then underwent a significant technology migration without updating the analysis has a stale document. OCR views this as the same as having no current analysis. The key word in the regulation is “accurate,” and an outdated analysis is not accurate.

No documentation. HIPAA requires organizations to maintain documentation of their policies and activities. A verbal discussion about security risks does not satisfy the requirement. The analysis needs to exist as a written document that can be produced for OCR when requested.

Risk analysis without a risk management plan. The risk analysis identifies the risks. The risk management plan describes what you are going to do about them, in what priority order, and by when. OCR expects both. Organizations that complete a thorough analysis but do not follow it with a plan for addressing identified risks have only completed half of what the regulation requires.

How to Document Your Risk Analysis Results

The format of your risk analysis documentation is not prescribed by the regulation. What matters is that it is comprehensive, organized, and clearly demonstrates that you followed a systematic process. OCR wants to see that you identified your ePHI environment, worked through threats and vulnerabilities in a structured way, assigned risk levels, and have a basis for the security decisions your organization has made.

A well-structured risk analysis document typically includes an executive summary, your scoping methodology, the asset inventory, a risk register with threat-vulnerability-likelihood-impact-risk level columns for each identified risk, your current control documentation, and a summary of findings that feeds into your risk management plan.

The risk register format is particularly useful because it gives you a structured way to track risks over time, document remediation actions, and demonstrate to OCR or an auditor that you have been actively managing your risk posture rather than treating the analysis as a one-time compliance exercise.