What a Real HIPAA Risk Assessment Includes (and What a Checklist Misses)

Most medical practices we talk to have something on file called a risk assessment. Sometimes it is a questionnaire a vendor filled out years ago. Sometimes it is a short report that came with a software purchase. Sometimes it is a folder nobody has opened since the person who made it left.

The HIPAA Security Rule asks for something more specific than that, and the difference matters when an insurer, a hospital partner, or a regulator asks to see it. This article walks through what the rule expects, what a thorough assessment looks like in practice, and where we usually find the surprises.

If you are a physician, administrator, or practice manager, this is written for you. You do not need a technical background to follow it.

What does the HIPAA Security Rule require?

The Security Rule requires every covered practice (and every business associate) to conduct an accurate and thorough assessment of the risks to the electronic patient information it holds. That requirement sits at 45 CFR 164.308(a)(1), and HHS describes it as the first step in complying with the rest of the rule.

The rule does not prescribe a method or a template. A two-provider office and a multi-site group are not expected to produce the same document. What the rule does expect is that the assessment covers all of the electronic patient information the practice creates, receives, keeps, or sends, and that it is written down.

What does a real HIPAA risk assessment include?

HHS guidance describes a set of elements any risk analysis should contain, whatever method is used. In plain terms:

1. Scope. Every system and location where patient information lives or travels. The EHR is the obvious one. Email, scanners, the phone system, imaging equipment, laptops that go home, and the billing company's portal are the ones that get missed.
2. Threats and vulnerabilities. What could reasonably go wrong, and what weaknesses would let it happen.
3. Current safeguards. What is already in place, and whether it is set up and used the way everyone assumes.
4. Likelihood. How probable each problem is in your environment.
5. Impact. How much damage it would do to patients and to the practice.
6. Risk level. Likelihood and impact together, so the list can be put in order.
7. Documentation. The findings in writing, in a form you can hand to someone.
8. Review. A plan to revisit it as things change.

The sixth item is the one that makes an assessment useful. A list of forty findings with no order is hard to act on. A list that says "these five first, and here is why" is a plan.

How is that different from a checklist or a gap analysis?

A checklist asks whether a control exists. Do you have a firewall? Is there a password policy? Is antivirus installed? Those are fair questions, and a gap analysis built from them tells you which required items are missing.

HHS has said plainly that a gap analysis by itself does not satisfy the risk analysis requirement. The reason is that it never asks the second question: given how this particular practice works, what could go wrong, and how bad would it be?

Two practices can check the same boxes and carry very different risk. One keeps its server in a locked room with tested backups. The other has the same server under a desk at the front counter and a backup nobody has tried to restore. The checklist looks identical.

Where do practices usually find surprises?

In our experience working with medical groups across Colorado, the technical scan is rarely where the biggest surprises come from. They come from five areas that nobody owns day to day.

Accounts that should not still work. A staff member leaves and the EHR login is turned off, but the email account, the remote access, the scheduling system, and the shared mailbox are not. We also find accounts nobody can explain: a login created for a vendor years ago, a test account, a former provider who still has administrator rights. Each one is a way in, and most practices do not have a single list of who has access to what.

No clear answer on what to keep. Most practices either keep everything forever or delete on instinct. Email, files, and shared folders pile up with patient information in them, and nobody has decided what gets archived, for how long, and why. Part of that answer is legal (HIPAA documentation rules, state record requirements, payer contracts, and what your attorney wants preserved if a dispute comes up). That makes it a decision for the practice's leadership with legal input, not something IT should guess at. Our part is showing what exists and where, so the decision can be made.

Cloud systems nobody is watching. Cloud services make sharing easy, and that is also the problem. We find files shared by link with people outside the practice, folders whose permissions were opened for a project and never closed, and connections between systems (API keys and app authorizations) that were set up for a vendor or a tool the practice stopped using. They keep working quietly until someone turns them off.

AI tools nobody approved. This is the newest one, and it is growing faster than the others. Staff are using AI chatbots to draft letters, summarize notes, and answer questions, often on personal accounts the practice has never seen. AI features are also arriving inside software you already own: meeting note-takers, transcription, email assistants, browser add-ons. Some of these tools are connected to mailboxes and file shares so they can do their work. The question for a risk assessment is simple: which AI tools touch patient information, who turned them on, and is there a Business Associate Agreement behind each one? Most practices cannot answer that today, because nobody has made the list. We build AI automation ourselves, so this is not an argument against using it. It is an argument for knowing where it is. (We wrote about the settings side of this in an earlier article.)

Training that never gets tested. Most practices do annual HIPAA training. Far fewer have sat down and walked through a scenario: the EHR is unavailable on a Monday morning, a laptop goes missing, a staff member reports clicking something they should not have. A tabletop exercise takes about an hour around a table, and it tends to surface simple gaps (who calls whom, where the contact list is, who decides what to tell patients) that no policy document reveals.

None of these exist because anyone was careless. They exist because each one sits between job descriptions.

That is why we do the work in three parts: technical testing, a review of policies and agreements, and an in-person visit to each location. Our risk assessment page describes the process in more detail.

What should you have in hand when it is done?

A finished assessment should leave you with three things.

The first is a written report of what was found, tied to the parts of the Security Rule each finding relates to. This is the document you produce when someone asks for your risk analysis.

The second is a remediation plan in priority order. The rule pairs risk analysis with risk management, which means deciding what to fix and following through. An assessment that stops at the findings is half the job.

The third is a clear picture of who owns what. Some items belong to your IT provider. Some belong to the practice (training, privacy practices, how staff handle records requests). Our HIPAA compliance page lays out how that split usually works.

How often should it be done?

The rule does not set a schedule. HHS describes risk analysis as an ongoing process and notes that some organizations do it annually and others less often, depending on their circumstances.

We recommend reviewing it once a year and any time something significant changes: a new EHR, a new location, a merger, a move to a different IT provider, or a security incident. A steady yearly review is far easier than rebuilding the whole thing every few years.

It is also worth knowing that HHS has proposed updates to the Security Rule that would make several of these expectations more specific. We covered that in an earlier article.

Practical starting points

If you are not sure where your practice stands, these are the first things we would look at.

1. Find your most recent risk assessment and check the date. If it is more than a year or two old, or nobody can find it, start there.
2. Make a list of everywhere patient information lives. Include email, cloud storage, devices that leave the building, and outside vendors.
3. Ask for a list of every active account in every system and compare it to your current staff list.
4. Pull your list of vendors and confirm there is a signed Business Associate Agreement for each one that touches patient information.
5. Ask your staff which AI tools they use for work, and ask in a way that gets honest answers. You are building a list, not looking for someone to blame.
6. Pick one scenario and talk it through with your team for an hour. Write down every question nobody could answer.

None of this requires a consultant. If the answers are uncomfortable, that is useful information, and it is normal.

How this fits with day-to-day security

An assessment is a snapshot. What keeps the picture accurate between assessments is the routine work: patching, monitoring, access reviews when staff change, and keeping documentation current. That is the difference between being ready when someone asks and scrambling to assemble paperwork. Our managed security and healthcare IT pages describe how we handle that side.