When the Office for Civil Rights opens an investigation after a breach report, the first document request is almost never about the breach. It's a request for your HIPAA security risk analysis — the current one, the prior versions, and the risk management plan that came out of it. Practices that hand over a four-year-old PDF produced by a vendor who no longer serves them tend to end up with a second finding on top of the original incident.

This article explains what the risk analysis requirement actually says, who inside your practice performs each step, how often you have to revisit it, and what the finished evidence file looks like when someone outside your organization asks to see it.

The Regulation Is Two Sentences Long, and That's the Problem

The requirement lives at 45 CFR 164.308(a)(1)(ii)(A). It directs covered entities and business associates to "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 is a required implementation specification, not addressable. There is no practice size below which it stops applying. A two-provider dermatology office and a 40-site orthopedic group have the same obligation, scaled differently.

The paired requirement at 164.308(a)(1)(ii)(B) — risk management — is where most practices actually fall short. Identifying risk without documenting what you decided to do about it, and when, leaves half the obligation unmet. OCR has treated the two as a unit in its enforcement posture, and its final guidance on risk analysis spells out the elements it expects to see.

How Often Must You Conduct a HIPAA Security Risk Analysis?

The Security Rule sets no fixed interval. It requires review and update "as needed" — but three practical triggers define the real cadence:

  • Annually. A full review at least once every 12 months is the defensible baseline, and it is what OCR investigators and most cyber liability underwriters expect to see dated.
  • On material change. New EHR, new imaging system, new location, remote work expansion, a new vendor touching ePHI, a merger, or a change in how you handle backups all trigger an update to the affected scope.
  • After an incident. Any reportable breach or near-miss should produce a documented reassessment of the control that failed.

If your practice bills Medicare and reports under the Promoting Interoperability performance category, there's a separate hard deadline: the security risk analysis measure must be conducted or reviewed during the calendar year of the performance period. A risk analysis dated December of last year does not satisfy this year's attestation. Check the current-year specifications on the CMS Promoting Interoperability pages before you attest.

The Nine Elements OCR Looks For

HHS guidance breaks the analysis into discrete components. Treat them as section headings in your report, because that's how a reviewer will read it.

1. Scope

All ePHI you create, receive, maintain, or transmit — regardless of location or media. That means the EHR, but also the practice management system, the imaging archive, the scanner that emails PDFs, the front-desk laptop, the biller's home workstation, the text-reminder platform, the answering service, the phones that store voicemail, and the vendor cloud storage nobody in the office thinks of as a system.

2. Data Collection — the Asset Inventory

You cannot assess risk to systems you haven't listed. Build a table: system name, what ePHI it holds, where it physically or logically lives, who administers it, whether the vendor is a business associate, and whether encryption is in place at rest and in transit. This inventory is the single most useful artifact you will produce, and its absence is the most common reason a risk analysis gets called inaccurate.

3. Identify and Document Threats and Vulnerabilities

Threats are external and internal: ransomware, phishing, insider snooping, lost devices, vendor compromise, flood, power loss. Vulnerabilities are the weaknesses those threats exploit — shared logins at the nurses' station, no MFA on the remote desktop gateway, an unpatched imaging workstation running an operating system past end of support.

4. Assess Current Security Measures

For each threat-vulnerability pair, record what you already have in place and whether it is configured and working. "We have antivirus" is not an assessment. "Endpoint protection deployed to 14 of 16 workstations; two radiology PCs excluded by vendor requirement" is.

5. Determine Likelihood of Occurrence

6. Determine Potential Impact

7. Determine the Level of Risk

Use a consistent scale — high/medium/low is fine, as long as you define the terms in the document and apply them the same way to every row. NIST's methodology in SP 800-30 Rev. 1 is the standard reference, and NIST SP 800-66 Rev. 2 maps that methodology directly onto Security Rule standards, which makes it the most useful crosswalk available for a practice-level assessment.

8. Finalize Documentation

Dated. Signed by whoever owns it. Retained six years from creation or last effective date, per 164.316(b)(2).

9. Periodic Review and Updates

Document the review even when nothing changed. A one-page memo saying "reviewed 2025-11-14, no material changes to scope, three open remediation items carried forward" is evidence. Silence is not.

Who Does What: A Workable Assignment Model for a 15-Person Practice

Risk analysis fails when it's assigned to "IT" and nobody else. Split it explicitly.

  • Privacy or Security Officer — owns the document, sets the schedule, chairs the two working sessions, signs the final report, tracks remediation to closure.
  • Practice manager — supplies the operational reality: who uses which system, what workarounds staff have invented, which fax and scanning workflows actually exist.
  • IT provider or MSP — supplies the technical inventory, patch status, encryption status, backup test results, account and access lists. Ask for these in writing; a verbal "you're covered" is worthless as evidence.
  • Billing lead — identifies every downstream party receiving claims, remittance, or eligibility data.
  • Owner or managing physician — approves the risk management plan and, critically, the budget attached to it. Unfunded remediation is a finding waiting to happen.

A realistic timeline for a single-site practice: two weeks to gather inventory and vendor data, one 90-minute session to score risks, one week to draft, one 60-minute session to approve the remediation plan with owners and target dates. Four to six weeks elapsed, roughly 12 to 20 staff hours.

Where the Risk Analysis Collides With Your Vendor List

Every vendor in your asset inventory that creates, receives, maintains, or transmits ePHI needs a business associate agreement in place before the risk analysis can honestly mark that relationship as controlled. In practice, the inventory step is where practices discover the gaps: the transcription service onboarded two years ago with no agreement, the cloud backup provider whose BAA was never countersigned, the marketing firm with credentials to the patient portal.

Note that missing or inadequate BAAs show up repeatedly in the resolution agreements posted to the HHS breach portal and OCR's enforcement summaries. When your analysis surfaces a gap, close it in the same cycle rather than logging it as a risk for next year. You can generate a signature-ready Business Associate Agreement through a six-step wizard with PDF and DOCX export — one-time purchase, no subscription — which removes the usual excuse that legal review would take a month.

Then record the outcome in the risk register: vendor name, agreement execution date, subcontractor flow-down confirmed, and the date you'll re-verify.

The Evidence File: What You Hand Over

Assemble these in one folder, named by year, before anyone asks:

  1. The dated, signed risk analysis report covering all nine elements.
  2. The system and asset inventory it was based on.
  3. The risk register: each finding, its rating, the chosen response (mitigate, transfer, accept), the owner, the target date, and the closure date.
  4. Evidence of closure for completed items — MFA configuration screenshot, encryption report, signed BAA, revised policy with effective date.
  5. Prior-year analyses, to show the trend and that carried-forward items moved.
  6. Meeting notes or an approval memo showing leadership reviewed and funded the plan.
  7. Workforce training records tied to any risk the analysis identified as behavioral.

If you'd rather not build the report structure from a blank document, tools that automate HIPAA risk analysis reports and the supporting policy set will keep the nine elements and the register aligned. The free HHS/ONC Security Risk Assessment Tool is also a legitimate starting point for smaller practices — just remember that running the tool is not the same as completing the obligation. The output has to be reviewed, scoped correctly, and turned into a funded plan.

Four Failure Patterns That Produce Findings

The gap analysis wearing a risk analysis costume. A checklist of Security Rule standards marked compliant or not compliant is a gap analysis. It contains no threats, no likelihood, no impact, no risk ratings. OCR has been explicit that this substitution does not satisfy 164.308(a)(1)(ii)(A).

EHR-only scope. The analysis covers the certified EHR and nothing else. Meanwhile ePHI sits in email, on a shared network drive, in a spreadsheet the biller maintains, and on three phones.

No remediation trail. Risks rated high in 2023, still rated high in 2025, with no record of a decision either way. That pattern reads as knowing acceptance of high risk without documented rationale.

Outsourced and unread. A vendor-produced report nobody in the practice can explain. If your Security Officer can't walk an investigator through the top five risks and what you're doing about each, the document won't help you.

OCR launched a dedicated risk analysis enforcement initiative in late 2024 and has continued resolving cases under it through 2025, most involving smaller and mid-sized providers rather than health systems. The size of your practice is not protection.

What the Proposed Security Rule Update Would Change

HHS published a notice of proposed rulemaking on January 6, 2025 that would substantially tighten the Security Rule. As of December 2025 it is not final, so nothing in it is currently enforceable — but the direction of travel matters for how you build this year's file.

Among the proposals: a written risk analysis with specified mandatory content, a maintained technology asset inventory and network map, annual review, and reduced flexibility around several currently addressable specifications. Practices that already keep a real asset inventory and a dated register with closure evidence will have very little new work if the rule finalizes in something close to its proposed form. Practices relying on a stale PDF will have a project.

Start With the Inventory This Week

Pick a date in January for the working session, and spend December building the asset and vendor inventory. That single table drives scope, drives the BAA reconciliation, and drives the risk register. Everything else in the HIPAA security risk analysis follows from knowing exactly where your ePHI lives and who else can reach it.

If the inventory turns up vendors without executed agreements — and it usually turns up two or three — close those gaps before the report is signed rather than carrying them as open findings. Draft and export the missing Business Associate Agreements in an afternoon, file the signed copies with your risk register, and start the year with an evidence file that answers the first question anyone will ask.