HIPAA Risk Analysis vs. Risk Assessment: What Each Requires and How They Differ

Table of Contents

HIPAA Risk Analysis vs. Risk Assessment: What the Difference Means for Your Compliance Program

The terms "risk analysis" and "risk assessment" appear throughout HIPAA guidance, OCR enforcement letters, and compliance vendor proposals — often used interchangeably, often meaning different things depending on who is writing. The confusion is not trivial. Organizations that conduct the wrong activity, or conduct the right activity incompletely, consistently fail OCR scrutiny on the requirement that generates more enforcement actions than any other in the Security Rule.

This article defines what the Security Rule requires under 45 CFR 164.308(a)(1), how risk analysis and risk management relate to each other, where the breach notification risk assessment fits in as a separate obligation, and what OCR looks for when it investigates compliance. For a complete overview of HIPAA's rules, safeguard categories, and 2026 regulatory changes, see the HIPAA compliance complete guide.

What the Security Rule Requires

The HIPAA Security Rule, at 45 CFR 164.308(a)(1), establishes the Security Management Process standard. It requires covered entities and business associates to implement policies and procedures to prevent, detect, contain, and correct security violations. Under that standard, four implementation specifications are required — not addressable, required:

Risk Analysis — 164.308(a)(1)(ii)(A): Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the organization.

Risk Management — 164.308(a)(1)(ii)(B): Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

Sanction Policy — 164.308(a)(1)(ii)(C): Apply appropriate sanctions against workforce members who fail to comply with security policies and procedures.

Information System Activity Review — 164.308(a)(1)(ii)(D): Regularly review records of system activity — audit logs, access reports, security incident tracking.

Risk analysis and risk management are two separate required specifications within the same standard. Completing one without the other is a partial compliance failure — and OCR treats them independently. In 2026, OCR expanded its enforcement initiative to include risk management specifically, meaning organizations that conduct a risk analysis but fail to demonstrate that findings were acted on are now explicitly in the crosshairs.

Risk Analysis: What It Is and What It Must Cover

A HIPAA risk analysis is a documented, systematic evaluation of threats and vulnerabilities to ePHI across your entire organization — not a questionnaire, not a vendor scan report, not a one-time checklist. HHS guidance on 164.308(a)(1)(ii)(A) specifies nine elements that a compliant risk analysis must address:

1. Scope. The analysis must cover all ePHI your organization creates, receives, maintains, or transmits — regardless of where it lives. EHR systems, billing platforms, cloud storage, email, endpoints, servers, medical devices, portable media, and any third-party systems that touch ePHI are all in scope. Limiting the scope to the primary EHR and omitting email or cloud platforms is one of the most common gaps OCR finds.

2. Data collection. Identify and document where ePHI is stored, processed, and transmitted. This requires a data flow map — tracking ePHI from entry points (patient intake, lab interfaces, insurance integrations) through storage systems and transmission paths to downstream recipients. Without a data flow map, you cannot assess what you have not inventoried.

3. Threat identification. Identify all reasonably anticipated threats to ePHI. This covers both human threats (workforce members, external attackers, business associates) and environmental threats (fire, flood, power failure, hardware failure). "Reasonably anticipated" is the standard — not every conceivable threat, but all threats that a similarly situated organization operating in your environment should anticipate.

4. Vulnerability identification. Identify vulnerabilities in your current environment that could be exploited by identified threats. Missing MFA on remote access, unencrypted endpoints, outdated operating systems, unpatched software, misconfigured cloud storage — each is a vulnerability. Vulnerability identification should draw on technical scanning results, not just administrative review.

5. Control assessment. Evaluate the security controls currently in place and their effectiveness at addressing identified vulnerabilities. A control exists on paper but is not consistently enforced is not a functioning control for risk analysis purposes.

6. Likelihood determination. For each threat-vulnerability pair, determine the probability that the threat will exploit the vulnerability. This is where the analysis requires judgment — a ransomware threat exploiting an unpatched internet-facing server is high likelihood; a physical theft threat in a facility with badge access and no external visitor access is lower likelihood.

7. Impact assessment. Determine the potential impact on the confidentiality, integrity, or availability of ePHI if the threat successfully exploits the vulnerability. Impact is measured in terms of harm to affected individuals, organizational disruption, financial exposure, and regulatory consequence.

8. Risk determination. Combine likelihood and impact to assign a risk level to each threat-vulnerability pair. Most frameworks use a matrix — high/medium/low or a numeric scale. The risk level drives remediation priority in the risk management phase.

9. Documentation. Document the entire process — scope, methodology, data sources, threat and vulnerability catalog, control assessment, likelihood and impact ratings, risk levels, and the conclusions reached. The documentation is what OCR investigators review. An undocumented risk analysis, regardless of how thoroughly it was conducted, provides no compliance protection.

Risk Management: What Happens After the Analysis

Risk management — 164.308(a)(1)(ii)(B) — is the implementation of security measures to reduce the risks identified in the analysis to a reasonable and appropriate level. It is not a separate, optional activity. It is a required specification that directly follows from the risk analysis output.

In practice, risk management is a remediation plan tied to your risk register. For each identified risk above your acceptable threshold, you document: the control or measure you will implement, the person responsible, the target completion date, and the current status. This is typically maintained as a Plan of Action and Milestones (POA&M) — the same document structure used in CMMC and FedRAMP compliance programs.

The failure mode OCR cites repeatedly is not that organizations never conduct a risk analysis — it is that they conduct one, identify risks, and then do nothing with the findings. OCR's enforcement guidance is explicit: identifying vulnerabilities without addressing them creates additional liability. It demonstrates that the organization knew about the risks and chose not to act. A corrective action plan issued after an OCR investigation almost always includes a requirement to implement the risk management activities that the organization's own prior risk analysis recommended but never executed.

Under the proposed 2026 Security Rule update, risk management must be documented with measurable objectives and evidence of completed remediation — not just a list of open items. The shift is from "we have a POA&M" to "we can demonstrate that risks identified in the analysis were reduced to an acceptable level within a defined timeframe."

"Risk Analysis" vs. "Risk Assessment": The Terminology Problem

The HIPAA Security Rule uses "risk analysis" at 164.308(a)(1)(ii)(A). The Breach Notification Rule uses "risk assessment" at 164.402 to describe the four-factor analysis that determines whether an incident is a reportable breach. HHS and OCR documentation use both terms in guidance materials, sometimes interchangeably and sometimes with distinct meanings. Industry vendors use both terms to describe the same service.

For compliance purposes, the practical distinction is this:

Security Rule risk analysis (164.308) — the ongoing, enterprise-wide evaluation of threats and vulnerabilities to ePHI that drives your security program. Required. Annual at minimum under the proposed 2026 update. Produces a risk register and feeds into risk management.

Breach notification risk assessment (164.402) — the incident-specific four-factor evaluation conducted after a potential breach to determine whether notification is required. Required when a privacy incident occurs. Produces a documented determination of whether the incident is reportable.

These are two distinct activities with different triggers, different outputs, and different regulatory citations. An organization that has conducted a thorough Security Rule risk analysis has not automatically satisfied the breach notification risk assessment requirement for any specific incident — and an organization that correctly applies the four-factor test after an incident has not satisfied the ongoing Security Rule risk analysis requirement.

A third activity sometimes labeled "risk assessment" in vendor proposals is a privacy risk assessment — a review of how PHI is used and disclosed under the Privacy Rule, covering paper records, verbal disclosures, and BAA compliance. This is not explicitly required by the Security Rule but is considered a best practice and appears in OCR corrective action plans for organizations with Privacy Rule deficiencies.

What OCR Finds When It Investigates

OCR's Risk Analysis Initiative, launched in 2024 and expanded in 2026 to include risk management, has produced a clear picture of what organizations get wrong. The pattern across enforcement actions is consistent:

No risk analysis was ever conducted. The organization has been operating for years, transmitting ePHI through billing systems, EHRs, and email, and has never formally identified where that ePHI lives or what threatens it. This is not limited to small practices — OCR has cited mid-size healthcare systems for the same gap.

The risk analysis was not enterprise-wide. The organization analyzed its primary EHR but omitted email systems, cloud storage, remote access infrastructure, medical devices, or business associate connections. A partial risk analysis does not satisfy 164.308(a)(1)(ii)(A).

The risk analysis was conducted once and never updated. Systems changed, vendors changed, the threat landscape changed — the risk analysis did not. OCR's guidance requires ongoing evaluation. A 2021 risk analysis does not satisfy the requirement in 2026 if the organization's ePHI environment has materially changed since then.

Findings were not addressed. The risk analysis exists and identifies gaps — unencrypted laptops, missing MFA, unpatched systems — but the risk management plan was never implemented. OCR's 2026 expansion of the initiative specifically targets this pattern.

Documentation does not reflect what was done. The risk analysis was conducted informally, or the documentation is too thin to reconstruct the methodology, data sources, or conclusions. OCR investigators ask for the written analysis, not a description of the process.

How Frequently Must the Risk Analysis Be Conducted

The Security Rule does not specify a frequency — it requires risk analysis to be conducted "periodically" and updated in response to environmental or operational changes. OCR guidance interprets this as ongoing, and recommends at minimum a full annual review. The proposed 2026 Security Rule update formalizes the annual requirement, removing the ambiguity that organizations have used to justify multi-year cycles.

Triggers for an updated risk analysis outside the annual cycle: new systems or platforms that process ePHI, mergers or acquisitions that bring new ePHI environments into scope, new vendor relationships that access ePHI, significant changes to existing systems (EHR migrations, cloud platform changes), security incidents that reveal previously unidentified vulnerabilities, and regulatory changes that affect the threat landscape or compliance obligations.

The 2026 Security Rule proposed update adds specific triggers: technology refresh cycles, changes to business associate relationships, and identified security incidents must each prompt a risk analysis review. Organizations that review their risk analysis only on an annual calendar schedule and ignore these event-driven triggers will have gaps that OCR's expanded initiative is designed to find.

HHS's Security Risk Assessment Tool

HHS offers a free Security Risk Assessment (SRA) Tool, developed with the Office of the National Coordinator for Health Information Technology (ONC), designed to help small and medium-sized healthcare organizations conduct their risk analysis. The tool walks through the required elements — ePHI inventory, threat and vulnerability identification, likelihood and impact ratings — and generates a report that can be used as documentation.

The SRA Tool satisfies the basic documentation requirement for organizations that use it thoroughly and honestly. Its limitations: it is self-reported, it does not perform technical scanning or vulnerability assessment, and it does not substitute for the technical evidence gathering — configuration reviews, vulnerability scans, access log analysis — that a complete risk analysis requires. OCR has cited organizations that used the tool but produced incomplete or inaccurate results because they did not gather the underlying technical data the tool's questions require.

For organizations with complex environments — multiple facilities, extensive third-party integrations, cloud infrastructure, or CMMC obligations that overlap with HIPAA requirements — the SRA Tool provides a useful framework but typically needs to be supplemented with technical assessment work.

What a Defensible Risk Analysis Looks Like to OCR

Based on OCR corrective action plans, enforcement letters, and HHS guidance, a risk analysis that holds up under investigation has these characteristics:

It is documented in writing with a clear methodology — how threats were identified, how vulnerabilities were assessed, how likelihood and impact were determined, and what risk levels were assigned. The methodology does not need to follow a specific framework, but it needs to be coherent and reproducible.

It covers the entire ePHI environment — every system, every location, every third-party connection that creates, receives, maintains, or transmits ePHI. The scope is explicitly defined in the document.

It reflects the current environment. Infrastructure changes, new vendors, new platforms, and new workforce access patterns are reflected in the analysis. The date of the analysis and the date of the last update are documented.

It is connected to a risk management plan with specific remediation actions, responsible parties, target dates, and documented completion. Open items are tracked with current status. Completed items have evidence of remediation.

It was conducted by people with sufficient knowledge of the ePHI environment — not delegated entirely to a vendor who produced a generic report without reviewing actual system configurations, access logs, or network architecture.

The Connection to Cyber Insurance and the 2026 Security Rule

Cyber insurers now ask for evidence of a current, documented risk analysis during underwriting. The questions — when the last risk assessment was conducted, what it covered, whether findings were remediated — mirror what OCR asks in investigations. Organizations with documented, current risk analyses and evidence of completed remediation consistently receive better terms than those without.

The proposed 2026 Security Rule update formalizes annual risk analysis requirements, mandates that risk management be demonstrably completed rather than merely planned, and requires enhanced documentation with threat-vulnerability pairs and quantitative risk ratings. Organizations that have been treating the risk analysis as a periodic checkbox are facing a compliance program that demands ongoing operation — not a document produced when an auditor asks for it.

Stratify IT conducts HIPAA Security Risk Analyses for covered entities and business associates, including data flow mapping, technical vulnerability assessment, risk register development, and risk management plan documentation. We operate as a business associate and execute BAAs as a standard part of every healthcare engagement. Contact us to discuss what an assessment would cover for your environment, or explore our HIPAA compliance services.

Frequently Asked Questions

1. Who is responsible for conducting a HIPAA risk analysis?

OCR does not require a specific role or credential to conduct the risk analysis. The Security Officer typically owns the process, with technical input from IT staff. Smaller organizations often use a third-party consultant or managed IT provider. What OCR requires is that whoever conducts it has sufficient knowledge of the organization's ePHI environment — not that they hold a particular certification.

2. What is the difference between conducting a risk analysis in-house versus hiring a third-party consultant?

An in-house risk analysis using the HHS SRA Tool costs nothing beyond staff time but relies on self-reported data and may miss technical vulnerabilities requiring scanning tools or configuration review. A third-party assessment typically costs $2,000 to $20,000 depending on organizational size, includes technical evidence gathering, and produces documentation that holds up better under OCR scrutiny. For organizations without dedicated compliance staff, third-party assessments are generally more defensible.

3. Does completing a risk analysis mean the organization is HIPAA compliant?

No. A risk analysis identifies risks — it does not resolve them. Compliance requires completing risk management: implementing controls to reduce identified risks to a reasonable and appropriate level, documented with a remediation plan and evidence of completion. OCR's 2026 enforcement expansion specifically targets organizations that conduct risk analyses but never act on the findings. The analysis is the starting point, not the finish line.

4. What happens if OCR discovers an organization has never conducted a risk analysis?

OCR treats the absence as a direct violation of 45 CFR 164.308(a)(1)(ii)(A), regardless of whether a breach occurred. Penalties typically fall in the Tier 2 range — $1,452 to $72,596 per violation — with a corrective action plan requiring a completed analysis submitted to OCR for review. The absence also undermines every other Security Rule safeguard, since each is supposed to be informed by the risk analysis findings.

5. How does the HIPAA risk analysis relate to NIST frameworks?

HHS guidance on the risk analysis requirement draws from NIST SP 800-30 and SP 800-66. Organizations with NIST-aligned assessments for SOC 2, CMMC, or FedRAMP can often map existing work to HIPAA requirements. The threat catalog, likelihood and impact ratings, and risk register produced for a NIST assessment satisfy the structure OCR expects — provided the scope explicitly covers ePHI systems and is documented accordingly.

6. Can a CMMC risk assessment satisfy HIPAA risk analysis requirements?

Partially. CMMC Level 2 requires a NIST SP 800-171 risk assessment covering Controlled Unclassified Information. HIPAA requires a risk analysis covering ePHI. The methodologies overlap significantly, but HIPAA's scope includes Privacy Rule obligations and physical PHI that CMMC does not address. An organization subject to both should map the assessments together — one cannot fully substitute for the other.

7. How long does a HIPAA risk analysis typically take?

A small practice with one EHR, a handful of endpoints, and a short vendor list typically needs one to three weeks using the HHS SRA Tool. Mid-size organizations with multiple systems or locations need four to eight weeks. The most time-consuming step is data collection — building the ePHI inventory and data flow map before the analysis itself can begin.

8. Does the HIPAA risk analysis cover paper records, or only electronic systems?

The Security Rule risk analysis covers ePHI only. Paper records and verbal disclosures fall under Privacy Rule obligations and a separate privacy risk assessment — not explicitly required by the Security Rule but considered best practice. OCR investigations following a breach routinely examine non-electronic PHI handling alongside electronic controls, so organizations with significant paper PHI volumes should conduct both.