HIPAA Risk Analysis: The 9 Elements OCR Looks For in 2026
Last updated: August 19, 2026
A HIPAA risk analysis is the written assessment of where your electronic protected health information (ePHI) lives, what could go wrong with it, and how likely and how bad each failure would be. It is required, not optional, under 45 CFR § 164.308(a)(1)(ii)(A). It is also the one document the HHS Office for Civil Rights (OCR) asks for first in nearly every investigation, and the one most practices cannot produce. You will also see it called a security risk assessment or SRA. Same document, same rule. This guide gives you the plain-language definition, the nine elements OCR looks for, a worked example, a step-by-step method a small practice can follow this week, and the one system most analyses forget: the website.
TL;DR: Quick answer
The HIPAA risk analysis is a required implementation specification (45 CFR § 164.308(a)(1)(ii)(A)). Every covered entity and business associate must have one, in writing, and update it.
OCR's guidance names nine elements: scope, data collection, threats and vulnerabilities, current controls, likelihood, impact, risk level, documentation, and periodic review.
OCR's Risk Analysis Initiative, launched October 2024, has produced a dozen enforcement actions and expanded in 2026 to whether you acted on the findings.
The most common failure is scope: an analysis that covers the EHR and forgets the website, the forms, the vendors, and the backups.
A small practice can build a defensible one with HHS's free Security Risk Assessment Tool, a data-flow map, and the five steps below.
What is a HIPAA risk analysis, in plain terms
Think of a HIPAA risk analysis as a map plus a scorecard. The map shows every place patient data lives and moves. The scorecard rates, for each place, how likely something is to go wrong and how bad it would be. The rule's own words ask for an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of ePHI. Three ideas sit inside that sentence, and they map to three plain questions.
Confidentiality: could the wrong person see it? (a stolen login, a leaked email, a tracking pixel)
Integrity: could it be changed or corrupted without anyone knowing? (a bad restore, an unlogged edit)
Availability: could you lose access to it? (ransomware, an outage, a vendor shutting down)
The risk analysis answers those three questions for every system. It then feeds risk management (§ 164.308(a)(1)(ii)(B)), the required next step where you actually reduce the risks you found. The rule names no method. NIST's risk-assessment framework and OCR's own guidance both describe what any good method must produce, and both are free.
The nine elements OCR looks for
OCR published its risk analysis guidance in July 2010, and enforcement still measures every HIPAA risk analysis against it. Hit all nine and the document is defensible. Skip one and it is a finding waiting to happen.
Element | What it means | What it looks like for a practice website |
|---|---|---|
1. Scope | Every system holding ePHI, in every form and place | The site, its forms, its host, its vendors, and any old copies |
2. Data collection | Map where ePHI is stored, received, kept, and sent | Intake form to database to notification email to inbox |
3. Threats and vulnerabilities | What could go wrong, and the weakness it would use | Threat: an ad pixel. Vulnerability: it runs on the booking page |
4. Current security measures | What already protects each system | Host BAA, encryption, MFA, backups, logging |
5. Likelihood | How likely each threat is, given the controls | Plaintext form emails: high. Server room fire: low |
6. Impact | How bad it would be | Records exposed, notices owed, care disrupted |
7. Risk level | Likelihood times impact, ranked | Fix the highs first, document the lows |
8. Documentation | Written down, dated, kept six years (§ 164.316(b)(2)(i)) | The report plus the risk management plan |
9. Periodic review | Repeated on a schedule and after any material change | Yearly, plus after a redesign, new form, or new vendor |
A worked example: one intake form
Here is what one row of a HIPAA risk analysis looks like, so the nine elements stop being abstract. The system: the new-patient intake form on the practice website. Data flow: the patient types symptoms and insurance details, the form plugin stores them in the site database and emails a copy to the front desk. Threats and vulnerabilities: the email travels in plain text; the database sits on a shared host with no BAA; an analytics tag fires on the form page. Current controls: HTTPS on the page, nothing else. Likelihood: high, because every submission repeats the exposure. Impact: high, because every submission is identifiable health information. Risk level: high. Risk management plan: move the form to BAA-covered hosting with encrypted storage, switch to content-free notification emails, remove the tag. Review date: one year, or sooner if the form changes. That paragraph is one compliant HIPAA risk analysis entry. Multiply it by every system that touches ePHI and you have the document.
The scope failure that catches most practices
Here is the pattern OCR keeps finding. A practice runs a HIPAA risk analysis on the EHR and the office network. The document looks complete. Then a breach or complaint arrives through a system the analysis never named: the practice website. Its intake forms, its booking flow, its notification emails, its analytics tags, the host with no BAA, the staging copy nobody deleted. Every one of those is an ePHI system under element one, and every one was out of scope. Kaiser's 13.4-million-record tracking exposure and the Advocate Aurora and Novant settlements were website systems that a thorough analysis would have flagged. If your website collects patient data, it belongs in the HIPAA risk analysis by name, with its own rows. What that system needs to look like is mapped in our HIPAA compliant website guide, and the tickable version is our HIPAA compliance checklist. Whether your site is in scope at all is settled in who needs HIPAA-compliant hosting.
How to do a HIPAA risk analysis: five steps
A small practice can build a HIPAA risk analysis it can defend in a few working sessions. Follow the five steps in order.
Inventory every ePHI system. List them all: the EHR, the website, every form tool, the scheduler, the email, the backups, the laptops, and each vendor with its BAA status. The vendor side is explained in our HIPAA business associate agreement guide. If a system is not on this list, it is not in the analysis.
Map the data flows. For each system, write where patient data enters, where it travels, where it rests, and where it leaves. A one-page diagram is enough. This is element two, and it is where the website surprises people.
List threats, vulnerabilities, and current controls per system. Use the worked example above as the template. Be honest about the controls that exist versus the ones you assume exist.
Rate likelihood and impact, then rank. Low, medium, high is fine. Combine them into a risk level and sort. The highs become your risk management plan with an owner and a date each.
Document, date, and calendar the review. Store the report and the plan together, keep them six years, and set a yearly review plus a trigger for any material change: a redesign, a new form, a new vendor, an incident. That schedule is what keeps a HIPAA risk analysis current instead of historic.
HHS publishes a free Security Risk Assessment Tool built for exactly this size of practice. It walks the nine elements in plain questions. Use it, but feed it the website systems it will not know to ask about, or the HIPAA risk analysis it produces will have the same scope hole as everyone else's.
Why 2026 is the year to have one
OCR launched its Risk Analysis Initiative in October 2024 to enforce this one requirement directly. It reached a dozen enforcement actions by 2026, and in 2026 OCR expanded it to risk management: not just whether the document exists, but whether you acted on what it found. A missing or weak HIPAA risk analysis also appears in most of the ransomware settlements OCR has announced. The pattern in every action is the same. The organization could not produce an accurate and thorough analysis covering the breached system. Our healthcare data breach statistics track the settlement figures, and the 2026 penalty tiers run from $145 to $2,190,294 per violation. The document is cheap. Its absence is not.
The part practices cannot see from the inside
Here is the honest pain point. Steps three and four are easy for systems you understand and nearly impossible for the website, because the threats live in places an office cannot inspect: the scripts firing in visitors' browsers, the mail path the form plugin uses, the vendor chain behind the booking widget, the server logs. That is the gap our client-side compliance review fills. It is the website section of a HIPAA risk analysis, done for you: every form, script, and vendor mapped, with risk levels and fixes, written to drop straight into your document as its own rows. And the hosting-layer controls that element four asks about, encryption, access, logging, backups, and the BAA, come documented on our healthcare hosting, from $79 per month self-managed to $229 per month managed with migration included, so that section of your analysis writes itself. We sell both, so weigh that as a disclosure. The five steps above are yours either way. Tell us what your analysis covers today and we will tell you what it is missing.
Frequently asked questions
Is a HIPAA risk analysis required?
Yes. It is a required implementation specification under 45 CFR § 164.308(a)(1)(ii)(A), not an addressable one. Every covered entity and business associate must conduct and document one, and OCR requests it first in most investigations.
How often should a HIPAA risk analysis be done?
The rule says periodically. OCR's guidance and common practice say at least annually, and again after any material change: a new system, a new vendor, a redesign, or an incident. Element nine of the guidance is periodic review for exactly this reason.
Is a risk analysis the same as a risk assessment?
In HIPAA usage they are the same thing; HHS's free tool is even called the Security Risk Assessment Tool, or SRA Tool. Risk management is the different step: acting on what the analysis found, required under § 164.308(a)(1)(ii)(B).
Does my website need to be in the risk analysis?
If it collects, stores, or sends patient data, yes, by name. Forms, booking flows, portals, notification emails, analytics tags, and the host itself are all ePHI systems under the scope element. Leaving them out of a HIPAA risk analysis is the most common scope failure OCR finds.
Can I use a template?
As a starting structure, yes. As the finished product, no. OCR requires an accurate and thorough analysis of your systems, and a template filled with generic answers fails the accuracy test. HHS's SRA Tool is the safest scaffold because it forces you to answer about your own environment.
What is the difference between a threat and a vulnerability?
A threat is the thing that could go wrong: an attacker, a staff mistake, an outage. A vulnerability is the weakness it would use: an unpatched plugin, a shared login, a pixel on a patient page. The analysis pairs them, then rates the pair.
Recap: HIPAA risk analysis
To recap, a HIPAA risk analysis is the required, written assessment of every ePHI system's threats, controls, likelihood, and impact, ranked and reviewed. OCR measures it against nine elements and is actively enforcing it, now including whether you acted on the findings. The most common failure is scope, and the website is the system most often left out. Inventory everything, map the flows, rate honestly, fix the highs, write it down, and repeat yearly.
This article is general information, not legal advice. Regulatory citations reflect 45 CFR Part 164 and OCR's risk analysis guidance as of August 2026; enforcement details reflect public OCR announcements through 2026. Confirm your obligations with qualified counsel. We sell HIPAA compliant hosting and compliance reviews. Reviewed August 2026.
Sources
45 CFR § 164.308(a)(1)(ii)(A) and (B) (risk analysis and risk management): ecfr.gov
HHS OCR: Guidance on Risk Analysis Requirements under the HIPAA Security Rule
NIST: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
HHS OCR: Enforcement process and results
45 CFR § 164.316 (documentation retention): ecfr.gov