A laptop disappears from a billing manager's car. You notify 340 patients, file the breach report, and eleven weeks later a data request letter arrives from the HHS Office for Civil Rights. Item one on the list is not the police report. It is your risk analysis — every version of it, for the past six years, with dates. Practices that can produce that document usually close the case with corrective action. Practices that cannot end up negotiating a settlement about something other than the laptop. The HIPAA risk analysis requirements are the single most-cited failure in OCR investigations, and this article walks through exactly what you have to produce, who inside your practice produces it, and what the finished evidence looks like in a binder or a folder.

The Rule Text You Are Actually Being Measured Against

The obligation sits at 45 CFR 164.308(a)(1)(ii)(A), inside the Security Management Process standard. It is a required implementation specification, not addressable. There is no version of "we considered it and documented why it wasn't reasonable and appropriate."

The text asks you 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." Two words carry the enforcement weight: accurate and thorough. Accurate means it reflects your actual environment — the real systems, the real vendors, the real locations. Thorough means it covers all ePHI, everywhere it lives, not just the EHR.

The companion specification at 164.308(a)(1)(ii)(B) requires risk management: implementing security measures sufficient to reduce those risks to a reasonable and appropriate level. A risk analysis with no remediation plan attached satisfies half the rule and reads badly in an investigation.

Documentation retention comes from 164.316(b)(2)(i): six years from creation or from the date it was last in effect. That is why the OCR letter asks for six years of versions, not one.

How Often Do You Have to Update a HIPAA Risk Analysis?

The Security Rule does not name a calendar interval. It requires review and update on an ongoing basis, and specifically when something material changes. In practice, treat it as an annual cycle with event-driven refreshes. Redo or amend the analysis when:

  • You adopt a new EHR, practice management system, or patient communication platform
  • You open, close, or relocate a site
  • You add remote work, a new telehealth tool, or personal-device access
  • You experience a security incident or breach
  • You merge, acquire, or are acquired
  • A new business associate begins handling ePHI

If your practice participates in the Medicare Promoting Interoperability Program or reports the MIPS Promoting Interoperability category, the analysis must be conducted or reviewed within the calendar year of your EHR reporting period and before your attestation date. That is a firmer deadline than the Security Rule itself imposes. CMS publishes the current measure specifications through its Promoting Interoperability Programs resources.

The Nine Elements OCR Expects to See

OCR's Guidance on Risk Analysis lists the components that make an assessment defensible. Structure your document with these as literal section headings — it makes an investigator's job easy, which is entirely the point.

1. Scope of the analysis

All ePHI your practice creates, receives, maintains, or transmits — regardless of media or location. Servers, laptops, phones, tablets, copiers with hard drives, USB drives, cloud storage, backup tapes, the fax bridge, the answering service, the billing company's portal.

2. Data collection

Where ePHI actually lives and moves. This is the asset inventory and data flow map. Write down how you gathered it: interviews, network scan, vendor list, walkthrough.

3. Identify and document threats and vulnerabilities

Threats are natural, human, and environmental. Vulnerabilities are the weaknesses those threats could exploit. "Ransomware" is a threat; "no multifactor authentication on remote desktop" is the vulnerability that makes it plausible.

4. Assess current security measures

What controls exist today, and are they configured and actually in use? "We have encryption available" is not the same finding as "full-disk encryption is enforced by policy on all 23 laptops and verified in the endpoint console."

5. Determine likelihood of occurrence

6. Determine potential impact

7. Determine the level of risk

Use a consistent scale — a 3x3 or 5x5 likelihood-by-impact matrix is fine — and define the terms in the document so two different people rating the same finding land in the same cell.

8. Finalize documentation

Dated, versioned, signed by whoever owns security in your practice.

9. Periodic review and update

State your review cadence and the triggers listed above, and then hold to it.

NIST's SP 800-66 Revision 2 maps each Security Rule standard to concrete practices and is the reference most auditors and consultants work from. It is free and written for organizations that are not staffed with security engineers.

The Asset Inventory Most Practices Skip

Nearly every deficient risk analysis fails at step two. A practice runs a questionnaire, checks 60 boxes about policies, and never lists a single device or system. That document does not satisfy the HIPAA risk analysis requirements, because you cannot assess risk to ePHI you have not located.

Build a table with one row per system or device category and these columns: system name, vendor, what ePHI it holds, how many records, where it is hosted, who administers it, whether a BAA is signed, encryption status at rest and in transit, and authentication method. Fifteen rows is normal for a three-provider practice. Forty is normal for a multi-site group.

Two rows people forget: the multifunction copier in the back hallway, and the personal phones your providers use for on-call texting. Both have surfaced in OCR investigations as unlisted ePHI locations.

The vendor column drives a second obligation. Every entity in that column that touches ePHI needs a signed business associate agreement on file before the risk analysis is finalized, and a missing BAA belongs in your findings list until it is executed. If you find gaps, a signature-ready business associate agreement generator will close them faster than routing a redline through counsel for a $200/month vendor.

A Six-Week Workflow With Names Attached

Assign this like any other project or it will sit for a year.

Week 1 — Scope and inventory. Privacy officer and IT lead. Walk every room in every site. Pull the vendor list from accounts payable, not from memory; AP catches the subscriptions nobody told you about.

Week 2 — Data flows. Practice manager and front desk supervisor. Trace intake, scheduling, referrals, labs, imaging, billing, collections, and records release. Note every point where ePHI leaves your walls.

Week 3 — Control assessment. IT lead, with vendor documentation. Verify rather than assume: pull the encryption report, the MFA enrollment list, the last three months of backup restore tests, the user account roster.

Week 4 — Threat pairing and rating. Privacy officer runs a two-hour working session with the IT lead and one clinical representative. Rate each threat-vulnerability pair. Expect 30 to 60 pairs.

Week 5 — Risk management plan. Owner, target date, and cost for each finding rated moderate or above. This is 164.308(a)(1)(ii)(B) and it is where most of the enforcement risk actually lives.

Week 6 — Sign, distribute, calendar. Owner signs and dates. Store it where it survives staff turnover. Put the next review on the calendar with the same owner named.

Assembling all of that from scratch consumes 25 to 40 staff hours the first time. If you would rather spend those hours on remediation than formatting, automated HIPAA risk analysis reports and policy sets produce the nine-element document, the risk register, and the supporting policies in a structure OCR recognizes — leaving your team to verify the facts rather than build the template.

What the Documented Evidence Actually Looks Like

When OCR asks, you should be able to hand over one folder containing:

  1. The dated, signed risk analysis with all nine sections
  2. The asset and vendor inventory it was built from
  3. The risk register with owners, target dates, and completion evidence
  4. Prior-year versions going back six years
  5. Meeting notes or a memo showing management reviewed the findings
  6. Executed BAAs for every vendor in the inventory
  7. Evidence that remediation actually happened — change tickets, invoices, screenshots, training rosters

Item seven separates practices that close with technical assistance from practices that sign a corrective action plan. A perfect analysis with zero completed remediation reads as an organization that knew about its risks and did nothing.

Five Failure Patterns That Keep Showing Up

OCR's free Security Risk Assessment Tool, published jointly with ONC, exists precisely because these patterns are so common in small and mid-sized practices:

  • Treating a vendor checklist as the analysis. A gap assessment against the rule's standards is useful, but it is not a risk analysis. It has no threats, no likelihood, no impact ratings.
  • Scoping to the EHR only. Your EHR vendor's SOC 2 report covers their environment, not your laptops, your Wi-Fi, or your email.
  • One-and-done. An analysis dated 2019 with no updates is evidence of a lapsed program, not a compliant one.
  • Findings with no owner. A risk register where the "responsible party" column says "IT" will not survive scrutiny. Use a person's name.
  • Attesting to Promoting Interoperability without the document. Attesting yes to the security risk analysis measure with nothing behind it creates exposure with CMS in addition to OCR.

Worth watching: the Security Rule modernization proposed in January 2025 would make several currently addressable practices mandatory and would specify asset inventories and network maps as explicit components of the analysis. It had not taken effect as a final rule as of this writing, but the direction is clear — build the inventory now and you are ahead of it either way.

Your Next 30 Days

Pull whatever risk analysis you have. Check three things: is it dated within the last 12 months, does it list your actual systems and devices by name, and does it contain a remediation plan with owners and dates? If any answer is no, you have a documented gap in the HIPAA risk analysis requirements as of today, and the fastest fix is to start the six-week workflow this week rather than after an incident forces it.

If you want the document structure handled so your team can focus on verifying the facts and closing findings, generate your risk analysis and supporting policy set and use the saved hours on the remediation column — the part that actually protects your patients and your practice.