HIPAA · SECURITY RULE
Our other HIPAA guides cover the full compliance process for business associates and covered entities. Both list risk analysis as one step. This is the step itself, in full. OCR cites a missing or inadequate one more than any other Security Rule failure.
TL;DR
A HIPAA risk analysis is a documented, organization-wide assessment of the risks to your electronic PHI. The Security Rule requires it at 45 CFR 164.308(a)(1)(ii)(A). It covers every system that creates, stores, or transmits e-PHI, not a sample. It names your threats, your vulnerabilities, and the likelihood and impact of each combination. It gets written down, though the Rule sets no required format. Risk analysis is not risk management. Analysis finds the risks. Management fixes them, under a separate requirement.
Sources: HHS Office for Civil Rights · HHS Guidance on Risk Analysis · Federal Register, 28 January 2026
Why this one requirement shows up in almost every settlement #
Read enough OCR resolution agreements and a pattern appears. The breach is different every time. Ransomware, a stolen laptop, an unlocked server, a phishing email. The root cause is not. OCR keeps citing the same failure underneath. No accurate risk analysis, or one that missed the system that got hit.
That pattern now has a name. OCR’s Risk Analysis Initiative has produced 14 settlements. A separate ransomware enforcement sweep has produced 20. The two lists overlap constantly, because a ransomware investigation almost always finds the same gap. You cannot manage a risk you never analyzed.
What “risk analysis” means under the Security Rule #
45 CFR 164.308(a)(1)(ii)(A) requires you to conduct an accurate and thorough assessment. It covers the potential risks and vulnerabilities to your e-PHI. That means its confidentiality, its integrity, and its availability. That is the standard OCR checks your work against. Not “we ran a scan.” Not “we filled out a template three years ago.”
Two words carry the weight. Accurate means it reflects your actual systems, not a generic list. Thorough means it covers all of your e-PHI. It does not stop at the parts that were easy to reach.
164.308(a)(1)(ii)(B) requires something different: risk management. Analysis is the assessment. Management is what you do with the results. It is the safeguards you put in place to bring each risk to a reasonable level. OCR treats them as two separate obligations. A settlement can cite either one on its own.
164.316(b)(1) requires you to document the analysis. The Rule does not specify a format. A spreadsheet, a report, or dedicated software all satisfy it. The documentation just needs to be accurate and current.
The process, in seven steps #
OCR’s own guidance lists the elements a risk analysis should cover. This is that list, organized as a sequence you can run.
Set the scope #
Goal: define what counts as e-PHI in your organization, before you start looking for it.
The scope is all electronic PHI your organization creates, receives, maintains, or transmits. That includes any form and any system. That includes the obvious systems, like your EHR or claims platform. It also includes the ones people forget. Backup drives, a shared spreadsheet, a help desk tool, and a remote employee’s laptop.
What goes wrong: the scope quietly shrinks to the systems IT manages directly. A risk analysis that skips shadow IT and personal devices is not thorough. It does not matter what else it gets right.
Find where your e-PHI lives #
Goal: a data inventory you can point to, not an assumption.
Find every place that stores, receives, maintains, or transmits e-PHI. Walk every system in scope and confirm it. Do not just trust a diagram someone drew two years ago. Include the vendors and business associates who receive a copy.
What goes wrong: the inventory lists applications but skips the exports. A report that gets emailed monthly as a CSV is still e-PHI in transit. It needs the same attention as the database it came from.
Identify threats and vulnerabilities #
Goal: a documented list of what could go wrong. Note where you carry exposure to it.
A threat is something that could cause harm. A ransomware group, a careless employee, a failed hard drive. A vulnerability is the weakness a threat could exploit. An unpatched server, a shared login, a missing encryption setting. Document both, and connect them. A threat without a matching vulnerability is not a risk yet.
What goes wrong: the list gets copied from a template. It never gets checked against your actual environment. OCR’s settlements cite risk analyses that named generic threats. Those threats never got mapped to the organization’s real systems.
Assess your current security measures #
Goal: know what protections already exist, and whether they work.
List the safeguards you have in place today: access controls, encryption, backups, firewalls, training. Then check whether each one runs correctly, not just whether a policy document mentions it. A safeguard that exists on paper but sits disabled in production protects nothing.
What goes wrong: the assessment trusts the policy instead of the system. Confirm the setting, do not just cite the standard operating procedure that describes it.
Score likelihood and impact #
Goal: a likelihood rating and an impact rating for every threat and vulnerability pair.
Rate how likely each threat is to exploit the matching vulnerability. Base this on the safeguards you assessed in Step 4. Then rate the impact if it happens. Look at the confidentiality, integrity, and availability of the e-PHI involved. Use a consistent scale across the whole analysis. That way, you can compare the results to each other.
What goes wrong: every risk gets scored “high.” Nobody wants to be wrong in the other direction. A scale that never varies is not a scale. It tells OCR the analysis was not thorough.
Determine the risk level #
Goal: combine likelihood and impact into one risk level per pair. That way, you know what to fix first.
Multiply, average, or use a matrix. The method matters less than applying it the same way each time, and writing it down. This risk level feeds into risk management. That is the separate obligation under 164.308(a)(1)(ii)(B). There, you decide how to bring each risk down.
What goes wrong: the analysis stops at the risk level and never gets used. A risk register that nobody consults when setting the security budget failed at its one job.
Document it, and keep it current #
Goal: written findings under 164.316(b)(1), reviewed on a schedule you can defend.
Write down the scope, the inventory, and the threats and vulnerabilities. Add the safeguards, the scores, and the risk levels. Any format works. Then revisit it. The Rule sets no fixed interval. But a new system, a new vendor, or a security incident should trigger an update. Most organizations also run a full review every year.
What goes wrong: the document is thorough the year it gets written and untouched after that. An analysis from three system migrations ago is not accurate anymore. It does not matter what it says on the cover page.
The free tool OCR helped build for this #
The Office for Civil Rights and the Assistant Secretary for Technology Policy maintain a tool for this. They call it the Security Risk Assessment Tool. It now stands at version 3.7. OCR updated it this month. It walks a small or mid-sized practice through the same elements covered above. It produces a report you can keep as documentation.
It is built for organizations without a dedicated compliance function. A larger covered entity tends to outgrow it fast. So does a business associate handling e-PHI for multiple customers. It needs a risk register that tracks findings over time, not a point-in-time questionnaire. But the SRA Tool is a legitimate starting point, and it is free.
What a recent enforcement case looked like #
In June 2026, OCR settled with the health plan run by Spencer Gifts LLC for $450,000. A ransomware attack had exposed the records of 10,023 people. The settlement was OCR’s 14th action under the Risk Analysis Initiative. It was also its 20th ransomware-related enforcement action.
The citation was specific. The plan had failed to conduct an accurate and thorough risk analysis before the breach. It had also failed to implement reasonable policies and procedures as a result. Both failures point back to the same missing step.
“Effective cybersecurity starts with Security Rule compliance, ensuring that Security Rule provisions are implemented before a cyberattack occurs.”
Paula M. Stannard, OCR DirectorAnnouncing the Spencer Gifts settlement
The corrective action plan runs two years. It requires the plan to conduct an accurate risk analysis. It also requires the plan to revise its Privacy, Security, and Breach Notification Rule policies. The plan must also retrain its workforce. The risk analysis itself would have surfaced all three items. That happens when the analysis is thorough the first time.
| Culpability tier | Minimum per violation | Maximum per violation | Annual cap |
|---|---|---|---|
| Did not know, and reasonable diligence would not have found it | $145 | $73,011 | $2,190,294 |
| Reasonable cause, not willful neglect | $1,461 | $73,011 | $2,190,294 |
| Willful neglect, corrected within 30 days | $14,602 | $73,011 | $2,190,294 |
| Willful neglect, not corrected | $73,011 | $2,190,294 | $2,190,294 |
Both audiences need this, not just one
164.308(a)(1)(ii)(A) applies to covered entities and business associates alike. A vendor holding e-PHI for a healthcare customer owes the same risk analysis. So does the hospital down the street. Our guides cover the rest of the process. Read them next: business associates and covered entities.
Frequently asked questions #
How often do we need to redo the risk analysis?
The Security Rule sets no fixed schedule. OCR expects it to be an ongoing process. Update it when something material changes. That means a new system, a new vendor, an acquisition, or a security incident. Most organizations also run a full review at least once a year, on top of those triggers.
Is risk analysis the same thing as risk management?
No. Risk analysis is 164.308(a)(1)(ii)(A), the assessment that finds and scores your risks. Risk management is 164.308(a)(1)(ii)(B). It is the separate requirement to implement measures that reduce those risks to a reasonable level. OCR can and does cite either one on its own.
Does the risk analysis need to be in a specific format?
No. 164.316(b)(1) requires documentation, but the Rule does not prescribe a template, software, or structure. A spreadsheet works as well as dedicated software. It just needs to be accurate, cover the required elements, and stay current.
Can we just use the free SRA Tool from HHS?
For a small or mid-sized organization, yes. The Security Risk Assessment Tool, now version 3.7, walks you through the same elements OCR expects. It produces documentation you can keep. A larger organization, or one handling e-PHI for many customers, needs something different. It needs a risk register that tracks findings over time.
What if we have a risk analysis, but it is incomplete?
An incomplete risk analysis draws the same citation as a missing one. OCR’s settlements name analyses that existed but did not cover every system. Others were never updated after a material change. “Accurate and thorough” is the standard, not “exists.”
Does SOC 2 or ISO 27001 satisfy this requirement?
Not directly, though the underlying work overlaps heavily. A SOC 2 audit and an ISO 27001 risk assessment both require the same core work. You identify and score risks to information systems. That is most of what 164.308(a)(1)(ii)(A) asks for. Neither one is a legal substitute for a HIPAA risk analysis. But you can adapt the risk register from either into one.
Key takeaways #
- A missing or inadequate risk analysis is the most often cited failure. It shows up across OCR’s Risk Analysis Initiative and its ransomware enforcement sweep.
- 45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment. It must cover all of your e-PHI, not a sample.
- Risk analysis and risk management are separate requirements. Analysis finds the risk. Management fixes it.
- Document the analysis under 164.316(b)(1). Any format works, as long as it is accurate and current.
- The free SRA Tool, now version 3.7, is a legitimate starting point for smaller organizations.
- The requirement applies the same way to covered entities and business associates.
- An incomplete risk analysis draws the same enforcement risk as no risk analysis at all.
Run a risk analysis that survives an OCR investigation #
Nank.ai helps organizations across Canada and the United States build the risk analysis HIPAA requires. It also helps them keep that analysis current. A compliance manager tracks every finding and every update. The analysis stays accurate long after the year you wrote it.
