HIPAA Security Rule Risk Analysis: Required Steps and Documentation Checklist

Ask most health care IT teams whether their organization has a HIPAA risk analysis and the answer is usually yes. Ask to see it, and the answers get less certain. Sometimes it is a vendor questionnaire from a few years ago. Sometimes it covers the EHR and nothing else. Sometimes it lives in the mailbox of someone who left the organization.

That gap matters because the risk analysis is not optional paperwork. It is a Required implementation specification under the HIPAA Security Rule. It is the foundation for nearly every other safeguard decision you make. And an incomplete or outdated risk analysis is consistently among the deficiencies OCR cites most often in enforcement actions and resolution agreements, according to analyses of OCR enforcement data from Scrut and Patient Protect.

This article walks through what the regulation actually says, the steps a defensible analysis needs to cover, and a documentation checklist you can hold your own analysis up against, whether you run IT for a multi-hospital system or you are the entire IT department at a 25-bed Critical Access Hospital.

At a Glance

Requirement: Risk analysis, 45 CFR 164.308(a)(1)(ii)(A). Required, not Addressable.

Who: Every covered entity and business associate that creates, receives, maintains, or transmits ePHI.

What to do, in order:

Inventory every system, medium, location, and vendor that touches ePHI
Identify reasonably anticipated threats and vulnerabilities for each
Document the safeguards actually in place today
Rate likelihood and impact on confidentiality, integrity, and availability
Assign risk levels in a risk register
Build a risk management plan with owners and timelines
Document everything and retain it for six years
Update when your environment changes

Note: The analysis does not replace the separate Required risk management step at 164.308(a)(1)(ii)(B). You need both.

Rule status: The January 2025 proposed Security Rule changes are not final. The current rule remains in effect.

What the Regulation Actually Requires

The core text is one sentence. Under 45 CFR 164.308(a)(1)(ii)(A), a covered entity or business associate must "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."

It sits under the Security Management Process standard alongside three other implementation specifications, all of them Required: risk management, sanction policy, and information system activity review. Under 45 CFR 164.306(d)(2), Required specifications must be implemented. There is no documented-alternative path for this one.

The words "accurate and thorough" carry most of the weight. They tie back to the general requirements in 45 CFR 164.306(a), which require you to ensure the confidentiality, integrity, and availability of all ePHI you create, receive, maintain, or transmit, and to protect against any reasonably anticipated threats or hazards to it. An analysis that leaves out systems holding ePHI cannot meet that standard, no matter how polished the rest of it looks.

The rule does give you flexibility in how you do it. Under 45 CFR 164.306(b)(2), you must take into account your size, complexity, and capabilities; your technical infrastructure, hardware, and software security capabilities; the costs of security measures; and the probability and criticality of potential risks to ePHI. That flexibility applies to the approach and the safeguards you choose. It does not apply to whether the analysis gets done.

Who Must Comply and What Is in Scope

The requirement applies to every covered entity and to business associates, per 45 CFR 164.302. If you are a billing company, a cloud vendor, an IT services provider, or any other business associate handling ePHI on behalf of a covered entity, you need your own analysis. Your client's analysis does not cover you, and yours does not cover them.

Scope is where most analyses fall short. HHS guidance on risk analysis is clear that the analysis must cover all ePHI in any electronic media, including hard drives, portable devices, networks, and cloud services, regardless of where it lives or where it came from. In practice that means vendor-hosted systems, medical devices, backups, and remote access paths, not just the EHR.

Consider a hypothetical 25-bed Critical Access Hospital with a hosted EHR. The EHR vendor is the obvious line item. But ePHI also lives in the imaging archive, the backup appliance and its offsite copies, the lab and pharmacy interfaces, scanned documents on a file share, email, the laptops used by staff who chart from home, the VPN or remote access tool those laptops use, and the systems run by the outside billing company. If the analysis lists only the EHR, it is incomplete, and that incompleteness is exactly what OCR looks for.

The Steps a Defensible Analysis Covers

HHS does not prescribe a methodology. You can use any approach that achieves the required elements described in the HHS guidance. Those elements break down into a logical sequence.

Step 1: Inventory where ePHI is created, received, maintained, and transmitted

Start with what you already have. Your Active Directory computer and server objects, your network monitoring or scanning data, your application list, and your list of business associate agreements are all inventory sources. Then walk each department and ask where patient information goes: what gets scanned, faxed, exported, emailed, or copied to a spreadsheet. Capture the data flows, not just the systems. An interface engine moving HL7 messages between the EHR and the lab system is a transmission path that belongs in scope.

Step 2: Identify reasonably anticipated threats and vulnerabilities

For each system or group of similar systems, list the threats that could reasonably affect it and the weaknesses that could let those threats succeed. The regulation itself gives you starting categories. The contingency plan standard at 45 CFR 164.308(a)(7) names fire, vandalism, system failure, and natural disaster. Add the human threats health care organizations face every day: ransomware, phishing, lost or stolen devices, misuse by authorized users, and unpatched or unsupported systems.

Step 3: Document the safeguards actually in place

Record the administrative, physical, and technical safeguards protecting each asset today. Be honest about the difference between what a policy says and what is actually configured. If the policy requires encrypted laptops but three older units were never encrypted, the analysis should say so. This is where hidden problems surface, and surfacing them is the point.

Step 4: Determine likelihood and impact

For each threat and vulnerability pair, estimate how likely it is to occur given your current safeguards, and what the impact would be on confidentiality, integrity, and availability. This mirrors the "probability and criticality" factor in 45 CFR 164.306(b)(2)(iv). OCR does not prescribe a scoring scale or quantitative thresholds. Pick a scale, define what each level means in writing, and apply it consistently. If you have completed an applications and data criticality analysis under your contingency plan (an Addressable specification at 164.308(a)(7)(ii)(E)), it is a useful input for impact ratings.

Step 5: Assign risk levels in a risk register

Combine likelihood and impact into a risk level for each item and record the rationale. Practitioner guidance consistently notes that a yes/no questionnaire is not enough on its own; reviewers expect to see a risk register with scoring and the reasoning behind it. A single row might look like this:

Illustrative risk register entry (hypothetical)
Asset	Threat / Vulnerability	Current Safeguards	Likelihood	Impact	Risk
Backup appliance	Ransomware reaches backups; appliance joined to the production domain with shared admin credentials	Nightly backups; offsite copy weekly; no immutable copy	Medium	High (availability)	High

Step 6: Build the risk management plan

The analysis identifies risk. The separate Required specification at 45 CFR 164.308(a)(1)(ii)(B) requires you to "Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." For each significant risk, record the planned action, an owner, and a target date. An analysis with no plan attached shows you knew about a risk and did nothing with it, which is a worse position than most people realize.

Step 7: Document the whole thing

Write down the scope, the methodology, who participated, the dates, the results, and the decisions. The next sections cover what the regulation requires for that documentation.

Why the Risk Analysis Drives Addressable Decisions

Many Security Rule specifications are Addressable, including encryption and decryption at 45 CFR 164.312(a)(2)(iv) and automatic logoff at 164.312(a)(2)(iii). Addressable does not mean optional. Under 45 CFR 164.306(d)(3), you must assess whether each Addressable specification is reasonable and appropriate in your environment. If it is, you implement it. If it is not, you must document why and implement an equivalent alternative measure if reasonable and appropriate.

That assessment needs something to stand on, and the risk analysis is it. A decision not to encrypt a particular system, with no risk analysis behind it, is very hard to defend. The same decision backed by a documented analysis of that system's threats, safeguards, and risk level, plus a compensating control, is a different conversation.

One note on what is coming. HHS published a notice of proposed rulemaking on January 6, 2025, that would change the Security Rule, including eliminating the distinction between Required and Addressable specifications. As of November 14, 2026, that rule is not final, with final action projected for July 2027, according to Integrity HIT. The current rule remains in effect. A thorough risk analysis is useful under either version, so there is no reason to wait.

Documentation and Retention Obligations

The documentation rules live in 45 CFR 164.316. Under 164.316(b)(1)(ii), if the Security Rule requires an action, activity, or assessment to be documented, you must maintain a written (which may be electronic) record of it. Three Required implementation specifications follow:

Time limit, 164.316(b)(2)(i): Retain the documentation for six years from the date of its creation or the date when it last was in effect, whichever is later.
Availability, 164.316(b)(2)(ii): Make documentation available to the people responsible for implementing the procedures it covers.
Updates, 164.316(b)(2)(iii): Review documentation periodically and update it as needed in response to environmental or operational changes affecting the security of ePHI.

The "whichever is later" clause has a practical consequence. When you update the analysis, do not overwrite the old one. Save each version with its date so you can show what you knew and when. A dated folder on a backed-up share or a document library with version history both work. Fancy tooling is not required.

Documentation Checklist

Use this to check an existing analysis or to structure a new one. Each item maps to the regulatory basis or guidance behind it.

Document or Element	Basis
Scope statement and ePHI inventory covering systems, media, locations, data flows, and business associates	164.306(a)(1); 164.308(a)(1)(ii)(A); HHS guidance
Methodology description, including the scoring scale and definitions, participants, and dates	164.316(b)(1)(ii); HHS guidance
Reasonably anticipated threats and vulnerabilities for each asset	164.306(a)(2); 164.308(a)(1)(ii)(A)
Current administrative, physical, and technical safeguards for each asset, as actually implemented	HHS guidance
Likelihood, impact, and risk rating for each item, with written rationale	164.306(b)(2)(iv); HHS guidance
Risk management plan with actions, owners, and target dates	164.308(a)(1)(ii)(B)
Addressable specification decisions: implemented, or documented reason plus equivalent alternative	164.306(d)(3)
Dated, retained prior versions (six years from creation or last in effect, whichever is later)	164.316(b)(2)(i)
Evidence the documentation is available to those who implement it	164.316(b)(2)(ii)
Review log showing periodic review and updates after environmental or operational changes	164.316(b)(2)(iii); 164.306(e); 164.308(a)(8)

Where OCR Finds the Problems

OCR has made risk analysis a specific enforcement priority through its Risk Analysis Initiative. At least 12 settlements had been announced under the initiative by early 2026, each citing a failure to conduct an accurate and thorough risk analysis, according to reporting by McDonald Hopkins and Scrut. Reported examples include settlements with BST & Co. CPAs of about $175,000 and Health Fitness Corporation of about $227,000. Note that the list includes organizations that are not hospitals or clinics; business associates are squarely in scope.

Compliance practitioners describe a consistent pattern in these cases: the failure is usually scope, not effort. Organizations analyzed the EHR and left out imaging systems, research databases, or business associate systems. Others relied on a checklist that recorded whether a control existed without assessing risk. Smaller organizations also report difficulty keeping the analysis current as cloud and SaaS tools get added faster than the documentation keeps up. Those are practitioner observations drawn from secondary reporting, but they line up with what the regulation demands.

Keeping the Analysis Current

The regulation does not set a fixed review interval for the risk analysis. It does require ongoing maintenance through three provisions working together: 45 CFR 164.306(e) requires you to review and modify security measures as needed and update documentation; 164.308(a)(8) requires periodic technical and nontechnical evaluation in response to environmental or operational changes; and 164.316(b)(2)(iii) requires documentation updates in response to those changes. HHS guidance treats risk analysis as an ongoing process rather than a one-time project.

A practical approach is to pair a scheduled review on your calendar with event-based triggers. Revisit the analysis when any of these happen:

A new EHR, major upgrade, or new clinical application goes live
A new vendor or cloud service starts handling ePHI
New network-connected medical devices are added
Remote access, telehealth, or work-from-home arrangements change
A new location opens or a merger or affiliation occurs
A security incident occurs, including near misses

Updating does not mean starting over. Add the new asset to the inventory, assess it, adjust affected ratings, update the plan, and save a new dated version.

Tools and Methodology Resources

Because no methodology is mandated, you have options. The HHS guidance points to the Security Risk Assessment (SRA) Tool from ONC and OCR, designed for small and medium-sized practices, and references NIST Special Publications 800-30 and 800-66 as helpful frameworks that are not mandatory.

A tool gives you structure, but it does not decide scope for you. If the inventory you feed into it leaves out the backup appliance and the billing vendor, the output will too. The same caution applies to outside help: a consultant or IT services provider can do much of the legwork, but the organization still owns the analysis and the decisions in it, and your designated security official under 164.308(a)(2) should be able to explain it.

For a solo IT person, the realistic path is to own the technical inventory and safeguards work and pull in department leads for the data flow questions. Nursing, lab, radiology, health information management, and billing staff know where patient data actually goes, and they will find things the network diagram does not show.

Making It Defensible

A defensible risk analysis has four traits. It covers every place ePHI lives and moves. It is specific about threats, safeguards, and ratings, with reasoning written down. It is current, with dated versions to prove it. And it is tied to a risk management plan that shows action. The findings should also point your ongoing monitoring: the Required information system activity review at 164.308(a)(1)(ii)(D) calls for regular review of audit logs, access reports, and security incident tracking reports, and the systems your analysis rates highest are the natural place to focus it. If you can hand your analysis to someone outside IT and they can follow how you got from inventory to decisions, you are in good shape. If you cannot find it, that is your first action item.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.