HIPAA Security Risk Assessment: How to Do One

A HIPAA security risk assessment is a written analysis of the risks to every system that creates, receives, maintains, or transmits electronic protected health information. It is required by 45 CFR 164.308(a)(1)(ii)(A), not optional, and HHS guidance says it must cover nine elements: scope, data collection, threats and vulnerabilities, current security measures, likelihood, impact, level of risk, documentation, and periodic review. It is also the single failure the Office for Civil Rights cites most often.

Almost every organization that gets in trouble with OCR has some sort of document it calls a risk assessment. The problem is rarely that nobody did one. The problem is that the one they did covered the EHR and not the laptops, or it was completed four years and two acquisitions ago, or it listed risks and stopped there without a single treatment decision attached. The rule asks for something narrower and more specific than most people assume, and the good news is that it tells you what.

Does HIPAA require a risk assessment?

Yes, and it is a required implementation specification rather than an addressable one, which means there is no risk-based opt-out. The text at 45 CFR 164.308(a)(1)(ii)(A) reads: "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate."

The very next specification, 164.308(a)(1)(ii)(B), is the one people forget. Risk management is also required: "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." An assessment that identifies twenty risks and produces zero decisions satisfies the first specification and fails the second. OCR has signaled that its enforcement attention is moving in exactly that direction, from whether you did the analysis to whether you acted on it.

This applies to business associates too, not only to covered entities. If you are a SaaS company processing PHI on behalf of a clinic, the Security Rule lands on you directly, and the hospital's procurement team will ask to see your risk analysis before it signs.

What is the difference between a risk analysis and a risk assessment?

Nothing, in practice. The regulation says risk analysis, HHS guidance and the free federal tooling say risk assessment, and the industry uses both interchangeably. What does differ is risk analysis versus risk management: the analysis identifies and rates risk, and the management step reduces it. Those are two separate required specifications, and they are graded separately.

It is also worth separating the risk analysis from a gap assessment. A gap assessment checks your controls against a checklist of Security Rule standards. A risk analysis starts from your actual systems and the threats to them, and can surface a serious risk that no checklist item covers. You want both, but only one of them is in the regulation.

The nine elements a HIPAA risk analysis must include

HHS OCR publishes formal guidance on the risk analysis requirement, and it is unusually direct: it says there is "no single method or 'best practice' that guarantees compliance," points to NIST SP 800-30 as one example of a process, and then lists the elements a risk analysis must incorporate regardless of method. Those nine elements are the closest thing to a grading rubric you will get.

Element	What it means in practice	Where teams get it wrong
Scope of the analysis	All ePHI you create, receive, maintain, or transmit, in every form of electronic media, at every location	Scoping to the main application and leaving out laptops, backups, email, ticketing systems, and analytics warehouses
Data collection	Identify and document where ePHI is stored, received, maintained, or transmitted, through interviews, documentation review, and system review	Relying on memory instead of an inventory, so shadow systems never make the list
Identify and document potential threats and vulnerabilities	Reasonably anticipated threats, plus the vulnerabilities a threat could exploit, documented for each	Copying a generic threat catalog with no reference to the actual environment
Assess current security measures	What safeguards are in place, and whether they are configured and used correctly	Recording that a control exists without checking that it is switched on and working
Determine the likelihood of threat occurrence	The probability of each threat and vulnerability pair actually happening	Assigning likelihood with no stated basis, so every risk lands on medium
Determine the potential impact of threat occurrence	The criticality of the effect on confidentiality, integrity, and availability	Considering confidentiality only, and ignoring availability entirely
Determine the level of risk	A risk level assigned to every threat and vulnerability combination identified	Rating some risks and quietly dropping the ones with no obvious owner
Finalize documentation	The analysis written down. The Rule requires documentation but does not mandate a format	Findings that live in a consultant's slide deck instead of a maintained record
Periodic review and updates	An ongoing process, refreshed as the environment changes	A document dated three years ago that predates the current cloud stack

Read that list next to whatever you currently call your risk assessment. Most documents fail on scope, on likelihood and impact having no stated reasoning, and on the periodic review never happening.

How to do a HIPAA security risk assessment

Here is the sequence that produces something defensible. Budget two to four weeks for a first pass at a company of twenty to a hundred people, most of it spent on the inventory.

1. Draw the ePHI boundary first

Before anything else, list every system that touches PHI. Not the systems you meant to use: the ones people actually use. Production databases, object storage, backups and snapshots, log aggregation, the data warehouse, the BI tool sitting on top of it, support tooling, email, shared drives, and the laptops that pull extracts. Vendors count, which is why the vendor list and the BAA list should be the same list. This is the step that most often takes longer than expected, because the answer is usually somewhere other than where people assume, and it is worth using something that can map how data actually moves between your systems rather than reconstructing it from a whiteboard.

2. Collect the evidence, not the intentions

For each system, record what it holds, who can reach it, how access is granted and removed, whether it is encrypted at rest and in transit, and whether activity is logged. Pull this from the systems themselves. An interview tells you what someone believes is configured; the console tells you what is.

3. Name threats against the environment you actually have

Ransomware, a stolen laptop, a misconfigured storage bucket, a departing employee with lingering access, a compromised vendor, a lost phone with a mail client on it, an insider browsing records they have no business reason to see. Pair each threat with the specific vulnerability that would let it succeed. "Ransomware" on its own is not a finding; "ransomware, because backups are not tested for restore and are reachable with the same credentials as production" is.

4. Score likelihood and impact, and write down why

A simple high, medium, low scale on both axes is fine. The Rule does not mandate a scoring model. What matters is that a reader can see the reasoning: this is high likelihood because the control is absent, this is high impact because the system holds records for every patient. Unexplained numbers are the fastest way to make a risk analysis look manufactured.

5. Assign a risk level to every pair

Every threat and vulnerability combination identified gets a level. No skipping the awkward ones. If a risk has no owner, that is itself a finding.

6. Decide what you are going to do, and record the decision

This is the risk management specification, and it is where most assessments stop too early. Each risk gets an owner, a treatment (mitigate, accept, transfer, avoid), and a date. Accepting a risk is a legitimate answer if it is documented and someone senior signed it. Silence is not.

7. Put it on a schedule

The analysis is an ongoing process, not an annual artifact. Tie a refresh to real events: a new system holding ePHI, a new vendor with a BAA, an acquisition, a material change to infrastructure, or a security incident. An annual full review on top of that is the pattern OCR settlements suggest is expected, though the Rule itself sets no fixed interval.

What tools can you use for a HIPAA risk assessment?

There are three realistic options, and the right one depends on how much else you are being asked to prove.

Option	Cost	Good for	Where it runs out
HHS Security Risk Assessment Tool	Free	Small and medium providers. HHS says plainly that "use of this tool may not be appropriate for larger organizations"	It is a wizard producing a point-in-time document. No evidence collection, no owners, no recurring tasks, no cross-mapping
A spreadsheet	Free	A first pass, or a very small business associate with one or two systems	Version drift, no reminders, no audit trail of who changed a rating and when. It ages badly and OCR notices
Compliance software	$79 to $500 a month at the self-serve end	Teams that also owe SOC 2 or ISO 27001, or that need the risk register, evidence, and BAAs in one place	Overkill for a single-location practice with no enterprise customers asking for reports

The free federal tool is genuinely useful and underused, and if you are a ten-person clinic it may be all you need. The case for software is different: it is not that the assessment is hard, it is that keeping it current alongside evidence, policies, training, and BAAs is the part that quietly fails. If you want to compare what the category costs, we keep a breakdown of compliance software pricing with published figures only.

How often do you have to do a HIPAA risk assessment?

The Security Rule does not set an interval. It requires the process to be ongoing and security measures to be updated as needed, which is why HHS guidance frames it as periodic review rather than an annual event. In practice, annual is the working baseline most auditors and enterprise buyers expect, with an out-of-cycle refresh whenever something material changes: a new system holding ePHI, a new subcontractor, a move to a new cloud provider, or an incident. An analysis that predates your current architecture is treated as no analysis at all.

What OCR actually looks for

OCR launched a Risk Analysis Initiative at the end of 2024 aimed squarely at this specification, and it has produced a steady run of settlements since, typically with corrective action plans requiring a documented risk analysis and a risk management process. The pattern in those cases is consistent, and none of it is exotic: the analysis did not cover all ePHI, or it was not updated, or risks were identified and never treated.

So when you review your own document, ask the three questions an investigator would. Does the scope include every system holding ePHI, including the ones nobody wants to talk about? Is it current as of your present architecture? And for each risk rated high, can you point to what you did about it and when? If any answer is no, fix that before you buy anything.

Is the HIPAA Security Rule risk analysis requirement changing?

Not yet. HHS published a notice of proposed rulemaking, RIN 0945-AA22, in the Federal Register on January 6, 2025, and the comment period closed on March 7, 2025. As of August 2026 no final rule has been published, so the current Security Rule is still the one you are measured against. The proposal would make several things stricter, including moving encryption and multi-factor authentication from addressable to required and adding explicit asset inventory and network mapping duties. Notably, the asset inventory is already effectively demanded by the data collection element of a proper risk analysis, so a team that does this well today is largely building toward the proposal anyway. Plan against the rule in force and watch the docket.

Where the risk analysis fits in the rest of your program

The risk analysis is the first step of Security Rule compliance and the input to almost everything else: which safeguards you prioritize, what your policies need to say, where your training should focus, and which vendors need scrutiny beyond a signed BAA. It also does double duty. The same analysis feeds SOC 2 CC3.2 and ISO 27001 Clause 6.1.2, so if enterprise customers are asking for those as well, the work is shared rather than repeated. That is the argument for keeping it in a HIPAA compliance software platform that cross-maps instead of a standalone document: one risk register, several frameworks.

If you are earlier than that and still deciding what to put in writing, start with the risk register and the safeguards it feeds. And if the driver for all of this is an enterprise deal rather than a regulator, the companion piece on audit evidence examples covers what reviewers ask you to hand over.