The HIPAA risk assessment requirement confuses almost every practice owner, and for a good reason. The terms “risk assessment,” “risk analysis,” and “security risk analysis” get used interchangeably everywhere you look, yet to OCR, the precise wording matters. Mixing them up in your documentation is one of the fastest ways to fail an investigation you could have easily passed. Understanding the HIPAA risk assessment requirement correctly is the difference between a defensible compliance program and a costly finding.
Here is why this matters so much right now. Since launching its Risk Analysis Initiative in October 2024, OCR has made inadequate risk analysis its single most-cited enforcement finding, appearing in 13 of 20 recent enforcement matters (source: North Privacy Advisors, OCR enforcement data, 2026). This is not a technicality. It is the number one reason healthcare organizations pay HIPAA penalties.
This guide clears up the confusion once and for all. You will learn exactly what the HIPAA risk assessment requirement means, the real difference between a security risk analysis and a breach risk assessment, what OCR actually looks for, and how to make sure your practice has the right document on file. No jargon, just clarity.
The HIPAA risk assessment requirement actually refers to two different things. The primary one is the Security Risk Analysis, required under 45 CFR 164.308(a)(1)(ii)(A), which is an ongoing, documented evaluation that identifies and prioritizes risks to all your electronic protected health information. The second is the breach risk assessment under 45 CFR 164.402, a four-factor evaluation done only after a possible breach to determine if it is reportable. The terms “risk analysis” and “risk assessment” are often used interchangeably, but the legally required, proactive document OCR asks for first is the Security Risk Analysis. It is the most frequently cited deficiency in OCR enforcement.
Why the Terminology Is So Confusing
The confusion is not your fault. It is baked into the regulation itself. The HIPAA Security Rule requires an “accurate and thorough assessment of the potential risks and vulnerabilities” to ePHI, but the requirement itself is officially titled “Risk Analysis” (source: HHS.gov, 45 CFR 164.308(a)(1)(ii)(A)). So the rule uses both words in the same breath.
On top of that, vendors and consultants use the terms loosely. Some sell a “risk assessment” that is really a light questionnaire. Others use “security risk analysis” and “SRA” interchangeably. The result is a market full of similar-sounding services that deliver very different things.
Here is the clarity you need. When people talk about the HIPAA risk assessment requirement, they are almost always referring to the Security Risk Analysis, the foundational document required by the Security Rule. That is the one OCR asks for first. Understanding this distinction is the foundation of a real HIPAA compliance program, and it is where our work with medical clinics consistently begins.
The Security Risk Analysis: The Requirement That Actually Matters
The Security Risk Analysis, often abbreviated SRA, is the core requirement. It lives at 45 CFR 164.308(a)(1)(ii)(A), under the administrative safeguards section of the Security Rule, and it is marked “Required,” not “addressable” (source: HHS.gov). Every covered entity and business associate must complete and maintain one.
The security risk analysis HIPAA mandates is a proactive, ongoing process. Its job is to identify every risk and vulnerability to the confidentiality, integrity, and availability of all the ePHI your practice creates, receives, maintains, or transmits. It is not a one-time event and it is not a checkbox.
A proper security risk analysis HIPAA requires does two things. First, it identifies the risks by inventorying where all your ePHI lives and how it flows. Second, it evaluates each risk by likelihood and impact, producing a prioritized picture of where your practice is most exposed. This is the blueprint for every security decision you make afterward. Our free risk assessment is built to these exact standards.
The Breach Risk Assessment: A Completely Different Thing
Here is the distinction almost every practice misses. There is a second, entirely separate risk assessment in HIPAA, and it serves a completely different purpose.
The breach risk assessment lives under the Breach Notification Rule at 45 CFR 164.402. You perform it only after a possible breach has occurred, to determine whether the incident is serious enough to require notifying patients and HHS (source: HHS.gov, 45 CFR 164.402). It is reactive, incident-specific, and triggered by an event.
This breach assessment uses four specific factors: the nature and extent of the PHI involved, who accessed or received it, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. Understanding risk analysis vs assessment in this context is crucial, because these are two different obligations. One is the ongoing security foundation. The other is an incident-response tool. Our guidance on what to do after a HIPAA breach touches on when this second assessment applies.
Risk Analysis vs Assessment: The Key Differences
To settle the risk analysis vs assessment question clearly, here is how the two obligations compare side by side.
| Feature | Security Risk Analysis | Breach Risk Assessment |
|---|---|---|
| Legal source | 45 CFR 164.308(a)(1)(ii)(A) | 45 CFR 164.402 |
| Purpose | Identify and prioritize risks to all ePHI | Determine if a specific breach is reportable |
| Timing | Ongoing, at least annually | Only after a possible breach |
| Nature | Proactive and preventive | Reactive and incident-specific |
| Scope | All ePHI across the organization | One specific incident |
| OCR asks for it | First, in any investigation | Only if a breach occurred |
The takeaway is simple. When you hear “the HIPAA risk assessment requirement,” it almost always means the Security Risk Analysis. That is the document you must maintain continuously, and its absence is what draws OCR penalties. The breach risk assessment only becomes relevant if something goes wrong.
What OCR Actually Looks For in Your SRA
OCR does not just check whether you have a document. It evaluates that document against specific criteria drawn from its Final Guidance and Audit Protocol. Meeting the real SRA requirements means covering all of them.
Here is what a defensible security risk analysis must include:
A complete, current inventory of every system, device, and application that touches ePHI. A network diagram showing how ePHI flows through your practice. Identification of threats and vulnerabilities to that ePHI. An assessment of your current security measures. A likelihood and impact rating for each risk. A prioritized risk determination. And documentation of everything, because to OCR, if it is not written down, it did not happen.
The most common failure is what OCR calls the checkbox version: a thin questionnaire or a generic template that does not reflect your actual environment. That is exactly what OCR flags as deficient. Meeting real SRA requirements means a thorough, practice-specific analysis, which is why many practices turn to a partner. Our managed IT services and our understanding of how to read a risk assessment report help practices produce documentation that holds up.
The Companion Requirement Everyone Forgets
Finding your risks is only half the obligation. Sitting right next to the risk analysis requirement in the regulation is a second, equally important one: risk management, at 45 CFR 164.308(a)(1)(ii)(B).
These two provisions are placed together on purpose. The risk analysis identifies your risks. The risk management plan documents what you are actually doing about them. OCR investigates both, and in 2026 announced it would expand enforcement to include risk management, not just analysis (source: OCR, 2026).
This means a risk analysis that identifies problems but sits on a shelf is not enough. You must show that you acted on what you found. A finding of “high risk: no MFA” must be followed by a documented plan to deploy MFA. This is where our network and endpoint security work turns analysis findings into completed fixes, closing the loop OCR expects to see.
How Often Must You Do a Risk Analysis?
HIPAA does not specify an exact frequency for the security risk analysis, which trips up many practices. The absence of a stated interval does not mean “once and done.”
OCR guidance and industry best practice are clear: conduct a full risk analysis at least once a year, and update it whenever a significant change occurs (source: OCR guidance, 2026). A significant change includes adopting a new EHR, adding telehealth, moving to the cloud, opening a location, or experiencing a security incident.
The practices that get penalized almost always have a risk analysis that is either missing or years out of date. A three-year-old analysis with no updates does not meet the HIPAA risk assessment requirement, because it no longer reflects your actual environment. Treating the SRA as an annual, living process is what keeps you compliant and defensible. Our free risk assessment helps establish that cadence.
Note Worthy Info
- The legal term is “Risk Analysis,” at 45 CFR 164.308(a)(1)(ii)(A). It is marked “Required.”
- There are two different assessments in HIPAA. The ongoing Security Risk Analysis and the incident-triggered breach risk assessment.
- The Security Risk Analysis is what OCR asks for first. It is the most-cited deficiency in enforcement.
- A checkbox questionnaire does not meet the standard. OCR expects a thorough, practice-specific analysis.
- Risk analysis has a companion: risk management. Finding risks is not enough; you must act on them.
- Do it at least annually and after any major change. A stale analysis does not satisfy the requirement.
- Document everything. To OCR, if it is not written down, it did not happen.
The Bottom Line
The HIPAA risk assessment requirement is far less confusing once you understand the core distinction. The document that actually matters, the one OCR asks for first and penalizes practices for lacking, is the Security Risk Analysis under 45 CFR 164.308(a)(1)(ii)(A). The breach risk assessment is a separate, incident-only obligation. Knowing the difference is not academic. It is the foundation of a compliance program that survives scrutiny.
Make sure you have a current, thorough, written Security Risk Analysis, that you act on what it finds through a documented risk management plan, and that you update it annually. Do that, and you satisfy the most important and most-enforced obligation in HIPAA. If you are unsure whether your documentation meets the HIPAA risk assessment requirement OCR actually enforces, request a free risk assessment and we will show you exactly where you stand and what a defensible analysis looks like.
Frequently Asked Questions
1. What is the difference between a HIPAA risk analysis and a risk assessment?
The terms are often used interchangeably, which causes confusion, but they can refer to two different obligations. The Security Risk Analysis, required under 45 CFR 164.308(a)(1)(ii)(A), is an ongoing, proactive evaluation that identifies and prioritizes risks to all your ePHI. The breach risk assessment, under 45 CFR 164.402, is a separate, reactive evaluation performed only after a possible breach to determine if it is reportable. When people mention the HIPAA risk assessment requirement, they almost always mean the Security Risk Analysis.
2. Which one does OCR actually require?
Both, but for different situations. The Security Risk Analysis is required continuously and is the document OCR asks for first in any investigation. It is the single most frequently cited deficiency in OCR enforcement actions. The breach risk assessment is only required if a possible breach occurs, to determine whether you must notify patients and HHS. The ongoing Security Risk Analysis is the one every practice must maintain at all times.
3. What must a HIPAA Security Risk Analysis include?
A defensible SRA must include a complete inventory of all systems and devices that touch ePHI, a map of how ePHI flows through your practice, identification of threats and vulnerabilities, an assessment of your current safeguards, a likelihood and impact rating for each risk, a prioritized risk determination, and thorough documentation of all of it. OCR evaluates your analysis against these specific criteria, and a generic template or thin questionnaire will not meet the standard.
4. How often do I need to do a HIPAA risk analysis?
HIPAA does not specify an exact frequency, but OCR guidance and best practice require conducting a full risk analysis at least once a year and updating it after any significant change. Significant changes include adopting a new EHR, adding telehealth, migrating to the cloud, opening a new location, or experiencing a security incident. A risk analysis that is missing or several years out of date does not meet the requirement, because it no longer reflects your actual environment.
5. Is a security risk analysis the same as an SRA?
Yes. SRA is simply the common abbreviation for Security Risk Analysis. Both refer to the same requirement under 45 CFR 164.308(a)(1)(ii)(A). You may also see it called a HIPAA risk assessment, which adds to the confusion, but in the context of the ongoing Security Rule obligation, all three terms point to the same foundational document that every covered entity and business associate must maintain.
6. What is the risk management requirement, and how is it different?
Risk management, at 45 CFR 164.308(a)(1)(ii)(B), is the companion requirement to risk analysis. While the risk analysis identifies and prioritizes your risks, the risk management plan documents what you are actually doing to reduce them. OCR investigates both, and in 2026 expanded its enforcement focus to include risk management. This means a risk analysis alone is not enough; you must also show that you acted on the risks it identified through a documented plan.
7. What happens if my practice does not have a proper risk analysis?
A missing or inadequate Security Risk Analysis is the single most common finding in OCR enforcement actions, appearing in the majority of recent settlements. You can face significant civil monetary penalties even without a breach, simply for failing to maintain a proper analysis. If a breach does occur, the absence of a defensible risk analysis substantially increases your liability. This is why maintaining a current, thorough SRA is the most important step in HIPAA compliance.
