What a Risk Assessment Is Actually For

The common pattern in a small practice is a risk assessment completed once, filed, and never opened again. That produces a document, which is not the same as the thing the document was standing in for.

The document and the activity

A security risk assessment is usually encountered as a deliverable: something to be completed, often with outside help, so that it exists if anyone asks. Understood that way it is a one-time task with a clear finish line, and once the file is saved the task is done.

The activity it is meant to represent has no finish line. It is the ongoing question of where patient information actually lives in this practice, who can reach it, what would happen if any of that failed, and which of those risks are worth doing something about.

Why practices drift out of date without noticing

Nothing announces itself when an assessment goes stale. A new vendor gets added because a physician wanted a tool. A staff member leaves and their access is disabled in the main system but not in the two smaller ones. A workflow moves to a phone. A laptop starts going home.

Each of those is a reasonable operational decision made by someone doing their job. None of them arrives labelled as a change to the risk picture, which is exactly why an assessment written a year ago can describe a practice that no longer exists.

What the recurring version looks like

In practical terms it is a short recurring review rather than a project: what systems hold patient information today, who has access to each, which vendors touch it and whether there is a current agreement with them, what training has happened since the last review, and what would happen in the first hours if any of it stopped working.

The value is not that the answers change dramatically each time. It is that the small drift gets caught while it is still small, and while the person who introduced it still remembers why.

Ransomware moved this out of IT

For a long time this was treated as an IT topic, which is to say somebody else's topic. That framing became difficult to sustain once the realistic failure mode became a practice that cannot reach its records at all.

A practice that cannot open its schedule cannot see patients, cannot document, and cannot bill, regardless of how the regulation is worded. That makes recovery an operational question about how the day would run, and those are answers the operations side has to supply.

Where this stops and specialist advice starts

Everything above is about the operational habit, which is the part a practice manager can build. What the regulation specifically requires of a given practice, how it applies to a particular arrangement, and what any of it means in a dispute are questions for a professional who does that work.

This is one of the areas where the gap between a reasonable operational routine and an actual legal obligation is genuinely wide, and where the sensible move is to have someone qualified look at your specific situation.

The inventory everything else depends on

Underneath all of it sits one unglamorous artifact: a current list of the systems holding patient information, who can reach each one, and which outside parties touch it. Almost every other question becomes answerable once that list exists, and stays difficult while it does not.

It is also the item most likely to be out of date, because it changes quietly. A workable version tends to be short, kept somewhere obvious, and reviewed on the same cadence as everything else rather than maintained as its own project.