How to Do a HIPAA Security Risk Assessment (Step by Step)

The HIPAA Security Rule requires every covered entity and business associate to assess the risks to the ePHI it holds. Here is what the risk analysis requirement actually says, the step-by-step methodology OCR expects, and why no template can complete it for you.

The requirement: 45 CFR 164.308(a)(1)(ii)(A)

The HIPAA Security Rule's single most important obligation is the risk analysis, and it lives at 45 CFR 164.308(a)(1)(ii)(A). It sits inside the Security Management Process standard — 164.308(a)(1) — which requires you to implement policies and procedures to prevent, detect, contain, and correct security violations. Within that standard, the risk analysis is a "Required" implementation specification, not an optional or "addressable" one. There is no version of HIPAA compliance that skips it.

The regulation defines it precisely: you 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." Read that carefully. The risk analysis is the assessment step — it identifies and rates the risks. It is deliberately distinct from the very next specification, 164.308(a)(1)(ii)(B) Risk management, which requires you to "implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level." The analysis tells you where you stand; risk management is what you do about it. People routinely blur the two, but they are separate required specifications, and OCR treats them separately.

This obligation binds covered entities (most billing medical, dental, and behavioral-health practices) and business associates (vendors that create, receive, maintain, or transmit ePHI) alike. Like the rest of the Security Rule, it is scalable: a solo practice is expected to perform an assessment reasonable and appropriate to its size and resources, not the enterprise risk program of a hospital network. But "scalable" does not mean "skippable" — every regulated organization, no matter how small, owes a real risk analysis.

What the risk analysis has to cover

A compliant risk analysis is not a generic checklist or a one-page attestation. It is a structured examination of your own environment, and it has to cover four things end to end.

First, the full scope of your ePHI. You have to identify everywhere ePHI is created, received, maintained, or transmitted across your organization — your EHR or practice-management system, email, the front-desk workstation, clinician laptops and phones, your imaging or lab interfaces, the patient portal, telehealth tools, every cloud service, and every backup. You cannot assess risk to data you have not located, so an honest data-flow inventory is the foundation everything else stands on.

Second, the threats and vulnerabilities to that ePHI. Threats are what could go wrong (ransomware, a lost laptop, a phishing compromise, a misconfigured share, a natural disaster, an insider error); vulnerabilities are the weaknesses a threat could exploit (no multi-factor authentication, unencrypted devices, stale access for departed staff, unpatched systems). Third, the security measures already in place and whether they are configured and used correctly. And fourth, for each reasonably foreseeable threat-vulnerability pair, the likelihood it occurs and the impact if it does — combined into a risk level (for example low, medium, or high) that lets you prioritize. Those risk levels are the output the rest of your program depends on, because risk management (164.308(a)(1)(ii)(B)) acts on them in priority order.

The step-by-step methodology OCR expects

You do not have to guess at the method. HHS's Office for Civil Rights publishes Guidance on Risk Analysis that lays out the essential elements of a compliant assessment, and following them keeps you on conservative, well-trodden ground. In practice the work runs as a sequence of steps.

Define the scope (all ePHI the organization holds, in every form and location). Collect data on where that ePHI lives and how it moves — the inventory above. Identify and document reasonably anticipated threats and vulnerabilities to each system or data store. Assess the current security measures you already use against them. Determine the likelihood that each threat would exploit each vulnerability. Determine the potential impact if it did. Determine the level of risk by combining likelihood and impact. Finally, document the results — the identified risks, their levels, and the measures you will use to address them — and recognize the analysis as ongoing, to be reviewed and updated over time.

A few practical notes keep this real rather than theoretical. Rate likelihood and impact with reasons, not just a color; a one-line justification ("laptops are unencrypted and leave the building, so a loss is plausible and would expose ePHI") is what makes an assessment "accurate and thorough." Tie each rated risk to a planned action and an owner so the analysis flows directly into your risk-management plan. And be specific to your systems — naming your actual EHR, your actual backup target, your actual telehealth platform — because a generic assessment that could describe any practice is exactly what OCR investigators flag as inadequate.

How often, and what triggers a new assessment

A common misconception is that the Security Rule mandates an annual risk analysis. It does not state a fixed calendar cadence. What the rule and OCR guidance require is that the risk analysis be an ongoing process — performed periodically and updated whenever something material changes in your environment. The point is currency, not a date on a certificate.

In practice, two things drive the timing. The first is periodic review: most organizations refresh the analysis on a regular cycle so it never goes stale, and many programs adopt an at-least-annual cadence as their own internal standard. (Note that some adjacent programs — for example the Medicare Promoting Interoperability program for eligible clinicians — do impose their own annual requirement; that is a program rule, not the Security Rule text.) The second is significant change. A new EHR or a major module, a move to telehealth or a new patient portal, a new lab or imaging interface, an office relocation or remodel, a merger, or any reportable security incident should each trigger a fresh or updated analysis, because each one changes where ePHI lives and how it can be exposed.

The failure mode OCR sees most is the "one and done" risk analysis performed years ago and never revisited, or one that was never genuinely conducted at all. Treating the risk analysis as a living document — dated, repeated, and re-run after real changes — is both what the rule contemplates and the simplest way to stay defensible. HHS periodically updates the Security Rule, so confirm the current requirements at hhs.gov before you rely on any specific cadence.

Documentation, the SRA Tool, and the OCR expectation

The Security Rule requires you to maintain your policies, procedures, and required actions in writing and to keep that documentation for six years from creation or last effective date. For the risk analysis specifically, that means a written, dated record: the scope, the ePHI inventory, the threats and vulnerabilities identified, the likelihood and impact ratings with their reasoning, the resulting risk levels, who performed the assessment, and the evidence relied upon. If it is not written down, from OCR's perspective it effectively did not happen.

HHS gives you a free starting point. The Security Risk Assessment (SRA) Tool, published by ONC together with OCR, walks a small or mid-sized practice through the assessment with structured questions and produces a report. It is genuinely useful and it is free — and it makes the brand-honesty point cleanly: a tool, like a workbook, structures and records the assessment, but it cannot make the judgment calls about your systems for you. You still have to answer truthfully about your real environment.

Understand why this matters so much in enforcement. Failure to conduct an accurate and thorough risk analysis is one of the most frequently cited deficiencies in OCR investigations and settlements. Organizations are penalized not only for breaches themselves but for never having performed a proper risk analysis in the first place — because it is the foundational control the entire Security Rule is built on. A current, well-documented assessment is one of the strongest pieces of evidence you can show that your program is real. (This article is general information, not legal or compliance advice; confirm the current rules at hhs.gov and consult a qualified professional for your situation.)

What only your practice can do — and where a toolkit fits

Here is the honest division of labor, because it is the part buyers most often get wrong. The risk analysis must be done for your organization, against your actual systems. No vendor, tool, or template can hand you a completed analysis, because the substance of it — what ePHI you hold, where it flows, what your real weaknesses are, and how likely and damaging each risk is — is specific to how your office actually operates. That examination and those judgment calls are yours.

What a documentation toolkit does is supply the methodology and the workbook so you are not building the structure from scratch. The ComplianceDocs HIPAA Compliance Toolkits for Medical Practices and for Dental Practices each include a HIPAA Security Risk Assessment (Excel) workbook — laid out around the OCR steps above, with the threat list, scoring, and risk-register columns ready for you to fill in — alongside 18 editable policies (security management, access control, encryption, incident response, breach notification, and more) that the analysis feeds into. Both are a one-time $79 (current list price; a launch discount code may apply at checkout). The toolkit gives you the documented program and the framework to perform the assessment; you and your team perform it.

To be unambiguous: completing the workbook does not make your practice "HIPAA compliant" or "certified" — there is no HIPAA certification to buy, and compliance is the program operating, not the binder existing. What the workbook does is remove the slowest, blank-page part so your limited time goes to the work that actually protects patient information: examining your systems, rating the risks honestly, fixing what the analysis surfaces (that is the risk-management step, 164.308(a)(1)(ii)(B)), and keeping the assessment current as your environment changes.

Frequently asked questions

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

In practice they refer to the same thing, and HIPAA's own term is "risk analysis." The Security Rule requires it at 45 CFR 164.308(a)(1)(ii)(A) as an accurate and thorough assessment of the risks and vulnerabilities to the electronic PHI your organization holds. "Risk assessment" is the more common everyday phrase for the same exercise. What matters is not the label but that you actually identify where your ePHI lives, the threats and vulnerabilities to it, and the likelihood and impact of each — and document the result. Note this is distinct from "risk management" at 164.308(a)(1)(ii)(B), which is the separate step of implementing measures to reduce the risks you found.

How often does HIPAA require a security risk assessment?

The Security Rule does not set a fixed annual deadline. It requires the risk analysis to be an ongoing process — performed periodically and updated whenever your environment changes materially, such as adopting a new EHR, moving to telehealth, relocating, or after a security incident. Many practices adopt an at-least-annual cycle as their own internal standard to keep the analysis current, and some adjacent programs (like Medicare's Promoting Interoperability program) do require an annual analysis, but that is a program rule rather than the Security Rule text. The safest approach is to treat the assessment as a living document: repeat it on a regular cycle and re-run it after any significant change. Confirm current requirements at hhs.gov.

Can the free HHS Security Risk Assessment (SRA) Tool satisfy the requirement?

The SRA Tool, published by ONC and OCR, is a genuinely useful free resource that walks a small or mid-sized practice through the assessment with structured questions and produces a report. Using it can help you perform and document a compliant risk analysis. But the tool only satisfies the requirement if you complete it honestly and thoroughly for your actual systems — it structures and records the work, it does not make the judgment calls about your environment for you. Like any workbook, it is the methodology layer; the substance still has to come from examining your own practice. The output also needs to flow into a real risk-management plan to address the risks it surfaces.

Does buying a HIPAA toolkit or template count as my risk analysis?

No. A toolkit can give you the methodology and a structured Security Risk Assessment workbook, but it cannot be your completed risk analysis, because the analysis must reflect your actual ePHI, systems, and weaknesses. The regulation requires an assessment that is specific and accurate to your organization, and a generic document that could describe any practice is exactly what OCR investigators flag as inadequate. Templates remove the blank-page work and make sure you do not miss a required step or policy, but you and your team have to perform the assessment, rate the risks, and keep it current. Documentation speeds readiness; it does not replace the work or make you "compliant."

What happens if my practice never did a HIPAA risk analysis?

Failure to conduct an accurate and thorough risk analysis is one of the most frequently cited deficiencies in HHS Office for Civil Rights investigations and settlements. Practices are penalized not only for breaches themselves but for never having performed a proper risk analysis in the first place, because it is the foundational control the entire Security Rule depends on. A missing or stale risk analysis weakens your position significantly if OCR investigates a complaint or breach. A current, well-documented assessment — dated, specific to your systems, and updated after material changes — is among the strongest evidence that your HIPAA program is genuinely in place. This is general information, not legal advice; consult a qualified professional for your situation.

Related guides: HIPAA

Toolkits that help

← All articles