Your risk analysis is why OCR would call

If OCR ever investigates your clinic, the first document it asks for has a name, and the name is not “your policies.” It is your risk analysis. In investigation after investigation, that request is where the case is decided, because the most common finding in Security Rule enforcement is not a sophisticated technical failure. It is that no accurate and thorough risk analysis ever existed.

This is not a prediction. It is the stated shape of current enforcement, and it has a paper trail.

The requirement

Risk analysis is a required implementation specification of the security management process standard (45 CFR 164.308(a)(1)(ii)(A)): conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information held by the covered entity or business associate.

Not addressable. Required. There is no version of a HIPAA security program that does not start here, because everything else in the Security Rule is calibrated by it. The flexibility the rule gives you everywhere else (45 CFR 164.306(b)) is flexibility to respond to your risks, which presumes you know what they are.

And it comes paired with a second required specification that matters just as much: risk management (45 CFR 164.308(a)(1)(ii)(B)), which requires you to implement security measures sufficient to reduce the risks you found to a reasonable and appropriate level. Finding the risks and then filing the document is compliance with (A) and violation of (B). Hold that thought, because enforcement just caught up with it.

The enforcement reality, with receipts

In October 2024, OCR launched a dedicated enforcement program, the Risk Analysis Initiative, aimed at exactly one failure: entities that never conducted a compliant risk analysis. By OCR’s own count in its April 23, 2026 announcement, the initiative had reached 13 completed investigations, alongside 19 completed ransomware investigations.

That April announcement is worth reading closely, because it is four settlements at once, totaling 1,165,000 dollars across breaches affecting more than 427,000 people, and OCR’s finding in all four was the same: the entity failed to conduct an accurate and thorough risk analysis before the breach. The attacks were ransomware. The violation OCR wrote up was the missing analysis. That is the enforcement pattern in one sentence: the breach is how OCR arrives; the risk analysis is what OCR judges.

If you are thinking your clinic is too small for any of this, the March 5, 2026 MMG Fusion settlement is the correction: 10,000 dollars, with OCR explicitly noting it considered the entity’s financial condition. OCR scales the penalty to the organization. It does not skip the organization.

“The breach is how OCR arrives; the risk analysis is what OCR judges.”

And the initiative is evolving. OCR has stated that its focus is expanding from risk analysis to risk management: from “did you look” to “what did you do about what you found.” A clinic with a two year old analysis and an untouched list of findings is exactly the profile the expanded initiative describes.

What “accurate and thorough” actually means

OCR published guidance on what it expects a risk analysis to contain, and it has been enforcing against that shape for years. Stripped of the framework language, a compliant analysis does these things:

It covers all of your ePHI. Not your practice management system. All of it, wherever it lives and however it moves. The scope of the analysis is the scope of your data, which is why the analysis has to begin with an inventory: every system, device, app, and service that creates, receives, maintains, or transmits ePHI. You cannot assess risk to data you have not located, and an analysis whose scope is one system is not thorough by definition.

It identifies threats and vulnerabilities against that inventory. Real ones, specific to how you operate. Not “hackers” as an abstract category, but: credentials phished from a BCBA, an unencrypted tablet left in a client’s home, a former employee whose portal access nobody revoked, a data collection app syncing over open wifi, a video platform nobody signed a BAA with.

It assesses the security measures you already have. What is actually in place, actually configured, actually on. Not what the IT person set up in 2021 to the best of anyone’s recollection.

It rates likelihood and impact, and assigns risk levels. This is the step that turns a list of worries into a set of decisions. Some risks are likely and catastrophic, some are neither, and your money and attention are finite. The ratings are how you defend where you spent them.

It is documented, and it stays current. The analysis is a living record, reviewed periodically and updated when your environment changes: a new EHR, a new clinic location, a telehealth program, an AI notetaker someone started using. An analysis that predates half your systems is not an analysis of your clinic. It is an analysis of a clinic you used to run.

Why the downloaded template is not one

The template failure is always the same failure. A generic document lists generic risks for a generic provider, someone types the clinic’s name into the header, everyone attests, and the folder closes. It reads like compliance. It is the opposite: it is a document that proves, in writing, that nobody looked at the actual clinic.

The test is brutal and simple. If your risk analysis would be equally true of the clinic across town, it is not a risk analysis of your clinic. OCR’s guidance expects your systems, your data flows, your vulnerabilities, your ratings, your decisions. The value is not the document. The value is the looking.

There is a free starting point that is genuinely yours to use: the Security Risk Assessment Tool published by OCR and ONC, built for small and medium providers. It will not know your clinic for you, but it structures the work honestly, and it is a far better floor than a template that already contains the answers.

What this looks like for an ABA clinic

An ABA clinic’s risk profile is not a dentist’s, and the difference is the field. Your ePHI does not sit in one building behind one router. It rides along on tablets into living rooms, schools, and cars. It moves through a practice management system, a data collection platform, a telehealth service, a video library of sessions, a texting thread with a parent, and whatever your billing company runs. Your workforce turns over the way RBT workforces turn over, which makes orphaned access a standing threat rather than an edge case.

A risk analysis that reflects your clinic will therefore say things a hospital’s never would: the highest-likelihood loss event is a device leaving a home visit; the encryption decision on those devices is the difference between a lost tablet and a reportable breach; termination procedures have to run at RBT speed; the school contract creates a records question that needs its own answer. If your analysis does not sound like your operation, it was not an analysis of it.

What may change

The January 2025 proposed Security Rule (90 FR 800) would make the risk analysis requirements considerably more specific, including a written technology asset inventory and a map of how ePHI moves through your systems. It is a proposal, not law, and its final form and timing are genuinely uncertain. But notice what the proposal is: it is the inventory-first shape that OCR’s guidance and enforcement already reward. A clinic that builds its analysis on a real inventory today is compliant under the current rule and prepared for the proposed one, whatever happens to it.

The honest bottom line

The risk analysis is the least fakeable requirement in HIPAA, which is exactly why OCR built an enforcement program on it. A policy can be downloaded. Training can be a certificate. But an accurate and thorough analysis of your clinic either exists or it does not, and the difference is visible on the first page.

It is also the requirement with the best return. Done honestly, it is not paperwork about security. It is the moment you find the unencrypted tablet, the orphaned login, and the vendor without a BAA, while they are still findings and not incidents.