The first document OCR asks for is almost never the breach report. It's the risk analysis. A standard data request opens with some version of "provide a copy of the Covered Entity's most recent risk analysis conducted pursuant to 45 CFR § 164.308(a)(1)(ii)(A), including the date completed and the scope of systems evaluated" — and you typically have 30 days to respond. If your hipaa risk assessment is a checklist a vendor filled out in 2021, or a PDF nobody on staff can locate, that gap becomes the finding, independent of whatever incident triggered the letter.

This article walks through what a defensible risk assessment contains, who inside your practice owns each piece, how often it has to be refreshed, and what the paper trail looks like when someone outside your organization reads it cold.

What Is a HIPAA Risk Assessment?

A HIPAA risk assessment — formally, a risk analysis under the Security Rule — is a documented, organization-wide evaluation of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information your practice creates, receives, maintains, or transmits. It is a required implementation specification, not addressable. Every covered entity and every business associate must do it, regardless of size.

HHS guidance identifies nine elements it expects to see: defined scope, data collection, identification of threats and vulnerabilities, assessment of current security measures, likelihood determination, impact determination, risk level assignment, documentation, and periodic review. The OCR guidance on risk analysis requirements is short and worth reading in full before you start.

What It Is Not

A risk assessment is not a gap assessment. A gap assessment measures you against a control list — do you have encryption, do you have a sanction policy, yes or no. Useful, but it does not identify threats, assign likelihood, or produce risk levels. Auditors read a gap assessment and record it as evidence that a risk analysis was not performed.

It is also not a penetration test, not a vulnerability scan, and not a SOC 2 report from your cloud vendor. Those are inputs. And no product or consultant can "certify" your practice as HIPAA compliant — HHS does not run a certification program and does not endorse any tool.

Who Owns the Risk Assessment and What Calendar It Runs On

Assign it to a named person. The Security Rule requires you to designate a security official (§ 164.308(a)(2)); in a 12-provider practice that is usually the practice administrator or the privacy officer wearing a second hat. Whoever it is, their name goes on the document with a date.

The rule says "periodic" and gives no interval. In practice, three triggers should drive a refresh:

  • Annually. If you attest to the Security Risk Analysis measure under the MIPS Promoting Interoperability category, CMS expects the analysis or review to be completed within the calendar year of the performance period. Attesting in March using a document dated two years back is a false attestation, not just a HIPAA problem.
  • On material change. New EHR, new imaging system, a merged practice, a new remote-work arrangement, a new patient-texting platform, a location closure. Any of these changes the scope.
  • After an incident. Every reportable breach and every near-miss should feed back into the analysis and the risk register.

Budget real hours. A five-provider single-site practice with one EHR and a handful of vendors is a 15–25 hour effort the first time, less on refresh. A multi-site group with imaging, an on-prem server, a billing company, and a patient portal is considerably more.

Step One: Build the Scope Before You Score Anything

Scope failures are the most common defect. An analysis that covers "the EHR" and stops there is incomplete, because ePHI does not stay in the EHR.

The ePHI Asset Inventory

Walk the building and walk the data. Your inventory should list, for each asset: what it is, where it physically sits, who administers it, whether it holds or transmits ePHI, whether it's encrypted at rest, and who has access.

Assets practices routinely forget:

  • The front-desk workstation with a local scan folder full of insurance cards
  • Fax servers and multifunction copiers with internal hard drives
  • Ultrasound, EKG, and retinal cameras that store studies locally before upload
  • Personal phones used for on-call texting and photo capture
  • The billing manager's laptop and her home printer
  • Shared network drives holding old chart PDFs from a predecessor system
  • Backup drives in the manager's desk drawer
  • Voicemail systems and answering-service platforms
  • Google Workspace or Microsoft 365 mailboxes carrying referral attachments

Every one of those is in scope. The free SRA Tool from HHS and ONC gives you a serviceable inventory structure if you don't already have one, though you will want to extend it.

The Vendor List Is Half the Scope

Every asset inventory produces a second list: the outside organizations that touch that data. Your billing company, transcription service, IT managed service provider, cloud backup vendor, shredding company, answering service, patient reminder platform, and the consultant who remotes into your server at 9 p.m.

Each one needs a signed business associate agreement on file, and the risk assessment is where the absence becomes visible. When you find a vendor with no executed BAA — and you will find at least one — you can generate a signature-ready Business Associate Agreement through a guided six-step wizard and export it as PDF or DOCX the same afternoon. It's a one-time purchase, which matters when you're closing three or four gaps at once rather than signing up for another recurring platform.

Document the BAA date in your risk register row for that vendor. "BAA executed 2025-11-14, countersigned, stored in \\Compliance\\BAAs\\" is evidence. "We have BAAs" is not.

Step Two: Score Threats Without Overengineering It

You need likelihood, impact, and a resulting risk level for each identified threat-vulnerability pair. A three-by-three or five-by-five matrix is sufficient. What matters is that the scale is defined in writing and applied consistently — not that it's quantitative.

NIST Special Publication 800-66 Revision 2 maps Security Rule requirements to concrete safeguards and includes risk assessment tables you can adapt directly. It is the single most useful free reference for this work.

A Worked Row

Here is what one line of a real risk register looks like for a small practice:

Asset: Billing manager's laptop, Windows 11, used at home two days weekly.
Threat: Theft or loss of device off-premises.
Vulnerability: BitLocker not enabled; local export folder contains ~4,000 claim PDFs with names, DOB, member IDs, and diagnosis codes.
Current controls: Password login, screen lock at 15 minutes, no MDM enrollment.
Likelihood: Medium. Impact: High — a lost unencrypted device is a presumed breach requiring individual and, above 500 individuals, media notification.
Risk level: High.
Treatment: Enable BitLocker with escrowed recovery key; delete local export folder; reroute exports to mapped network share; enroll in MDM.
Owner: IT MSP lead. Due: 2026-01-15. Status: Open.

Note what encryption buys you: under the breach notification rule, ePHI rendered unusable through encryption meeting HHS specifications falls within the safe harbor. That single control converts a reportable breach into a documented non-event. Scan the OCR breach portal and count how many entries read "theft — laptop."

Step Three: The Risk Management Plan Is Where Practices Fail

Section 164.308(a)(1)(ii)(B) requires you to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. That's a separate, equally mandatory requirement. A beautiful risk assessment with no remediation plan attached fails half the standard.

Your plan needs, for each high and medium finding: the corrective action, a named owner, a target date, the budget if any, and a status field you actually update. Review it quarterly in a documented meeting. Fifteen minutes, dated agenda, attendee list, notes on what closed and what slipped.

When you accept a risk rather than remediate it — and sometimes that's the right call — write down why. "Legacy ultrasound cannot support current OS; segmented onto isolated VLAN with no internet route; replacement budgeted Q3 2026; accepted by [name], [date]." That is a defensible decision. Silence is not.

What OCR's Risk Analysis Initiative Changed

OCR announced a dedicated Risk Analysis Initiative in late 2024 and has been resolving cases under it throughout 2025. The pattern is consistent: an investigation opens after a ransomware event or a breach report, and the settlement centers on the entity's failure to conduct an accurate and thorough risk analysis — often years before the incident. The corrective action plans routinely require a fresh enterprise-wide risk analysis, a written risk management plan, policy revisions, and workforce retraining, monitored for a multi-year term.

Read that as a signal about sequencing. The risk analysis is the prerequisite to everything else in the Security Rule, and its absence is easy for an investigator to prove.

The Proposed Security Rule Rewrite

In January 2025, HHS published a notice of proposed rulemaking that would substantially overhaul the Security Rule — removing the addressable/required distinction, mandating asset inventories and network maps, requiring encryption of ePHI at rest and in transit with narrow exceptions, and setting explicit timeframes for activities including risk analysis updates. As of December 2025 it remains proposed, not final. Don't rebuild your program around a draft, but do note that everything in the proposal rewards practices that already maintain a current inventory and a live risk register.

What the Documented Evidence Actually Looks Like

Assemble one folder, and keep it where a covering administrator could find it in five minutes:

  1. The risk analysis report — scope statement, methodology, date completed, author, sites and systems covered, findings with likelihood/impact/risk level.
  2. The ePHI asset inventory — dated, with an owner per asset.
  3. The vendor register with BAA execution dates and links to the signed agreements.
  4. The risk management plan — open items, owners, due dates, closure evidence.
  5. Quarterly review minutes showing the plan is alive.
  6. Prior years' analyses, retained six years per § 164.316(b)(2).

That last one surprises people. The six-year retention requirement applies to the documentation itself, so you keep the superseded versions. They demonstrate a pattern of periodic review, which is exactly what the rule asks for.

Three Findings Almost Every Small Practice Has

  • Terminated users still active. Pull your EHR user list and compare it to payroll. The gap is usually two to four accounts.
  • No documented review of audit logs. Logging is on; nobody looks. Set a monthly sampling routine and sign the log review.
  • Undocumented remote access. Somebody's brother-in-law set up remote desktop in 2019 and it's still listening on the open internet.

Start This Week, Not Next Quarter

If your last risk assessment predates your current EHR, treat this as an open finding today. Block four hours, walk the office with a notepad, and build the asset inventory. That single artifact drives the scope, the vendor list, and the register.

If you'd rather not build the templates from scratch, hipaa.app automates the risk analysis report and the supporting policy set for practices that need audit-ready documentation without a consulting engagement. And when the vendor review surfaces a missing agreement — it will — produce the executed BAA before the week ends and close the row in your register.