If you run a small healthcare practice, you have almost certainly been told you need a “HIPAA risk assessment.” Maybe you bought a binder of policy templates, filled out a questionnaire your IT company handed you, or ticked through a compliance checklist and felt the relief of a task finally done. It’s an understandable place to land. The trouble is that none of those things, on their own, is the document HIPAA actually requires.
This is one of the most common and most expensive misunderstandings in small-practice compliance. A checklist tells you whether you did specific things. A risk assessment tells you where your patient data could be harmed and how badly. Those are not the same exercise, and the federal government cares about the second one. When the Office for Civil Rights (OCR) investigates a small practice after a breach, the missing or inadequate risk analysis is one of the findings that comes up again and again.
This post explains what a Security Risk Assessment genuinely is, why it’s legally required (not optional, not “addressable”), what it has to contain to count, the specific ways practices get it wrong, and what to actually do about it. No panic, no hype, just the honest shape of the requirement.
What the law actually requires¶
The requirement lives in the HIPAA Security Rule, and it is worth quoting because the exact words matter. Under 45 CFR §164.308(a)(1)(ii)(A), a covered entity must “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.” That sentence is the whole assignment, and it is more demanding than most owners realize.
Notice three phrases. “Accurate and thorough” means a shallow, guessed-at review does not satisfy the rule; the government expects you to have actually looked. “Potential risks and vulnerabilities” means you have to think about what could go wrong, not just confirm what you already have in place. And “electronic protected health information held by the covered entity” means all of it, everywhere it lives, not just the records inside your EHR.
The other thing to understand is a small but critical piece of HIPAA vocabulary. The Security Rule sorts its safeguards into two buckets: “required” and “addressable.” Addressable safeguards give you some flexibility in how (or occasionally whether) you implement them, as long as you document your reasoning. The risk analysis is not in that flexible bucket. It is flagged “required.” You do not get to decide it isn’t reasonable for your practice. Every covered entity and business associate that touches ePHI has to do one, from a hospital system down to a solo therapist with a laptop.
One caveat before we go further: this article is general education, not legal advice. Your specific obligations depend on your practice, your data, and your state, so treat what follows as a map, not a substitute for counsel when you need it.
Why a checklist isn’t a risk assessment¶
Here’s the heart of the confusion, so let’s be precise about it. A checklist, a gap assessment, a policy template kit, and a security questionnaire are all useful. They are also all different from a risk analysis, and none of them replaces it.
A checklist asks yes-or-no questions: Do you have antivirus? Are laptops encrypted? Is there a password policy? It measures whether you’ve done a predetermined list of things. That’s genuinely helpful for staying organized, but it can’t tell you whether the things on the list are the right things for your practice, or what you’re missing that isn’t on the list at all.
A gap assessment compares your current setup against a standard and flags the gaps. That’s closer, and often a useful input, but it typically stops at “here’s what’s missing” without asking how likely each threat is, how much harm it would cause, and therefore which gaps deserve your attention first.
A policy template kit gives you the written documents HIPAA also requires (access control, sanctions, breach notification, and so on). Those are real obligations, and you need them, but a binder of policies is a statement of what you intend to do. It is not an assessment of the risks to your data. You can have a perfect policy binder and still have no idea that patient data is sitting unencrypted on a former employee’s home laptop. And a security questionnaire from a vendor or insurer is just a data-collection form: it gathers facts, it does not analyze them.
The risk assessment is the analytical step that sits underneath all of those. It is where you inventory every place ePHI lives, name the realistic threats to each one, judge how likely and how damaging each threat is, and decide what to do. A checklist can be an ingredient in that process. It cannot be the process. The legal test isn’t “did you fill out a form”; it’s “did you accurately and thoroughly assess the risks.”
What a real risk assessment must contain¶
A risk assessment that would actually hold up has a recognizable anatomy. OCR’s own guidance on the risk analysis requirement describes the essential elements, and you can meet them in plain language at a small-practice scale. You do not need a six-figure consulting engagement. You need to do these things honestly and write them down.
A full inventory of where ePHI lives. This is the foundation, and it is the step most practices skip. List every place patient data is created, received, stored, or transmitted: your EHR, yes, but also billing systems, email, text messages, cloud drives, scanning apps, appointment-reminder services, staff laptops and phones, the front-desk workstation, backup drives, and any vendor that stores data for you. If you don’t know where the data is, you cannot possibly assess the risks to it.
Identification of threats and vulnerabilities. For each place data lives, what could realistically go wrong? Threats include theft of a device, ransomware, a phishing-compromised account, a lost phone, a snooping employee, a vendor breach, a fire or flood that destroys records. Vulnerabilities are the weak spots that let those threats land: an unencrypted laptop, a shared login, no backups, a missing Business Associate Agreement.
An assessment of current safeguards. What are you already doing to protect each system? Encryption, unique logins, access limits, backups, training. This is where a checklist genuinely earns its keep, as an input.
A rating of likelihood and impact. For each risk, how likely is it, and how bad would it be if it happened? This is the analytical core that separates a risk assessment from a list. It’s what lets you say “the unencrypted laptop is our biggest exposure” instead of treating every item as equal.
A risk level and a plan to address it. Combine likelihood and impact into a risk level, then write down what you’ll do about the significant ones and by when. That remediation plan (often called a risk management plan) is the reason you did the analysis in the first place.
Documentation, dated and retained. If it isn’t written down, it didn’t happen, as far as an investigator is concerned. The assessment has to be a document you can produce, and HIPAA requires you keep such records for six years.
A cadence for updating it. A risk assessment is not a one-time event. OCR expects it to be reviewed and updated periodically and whenever something material changes: a new EHR, a new location, a shift to telehealth, a significant new vendor. A five-year-old assessment describing a practice that no longer exists is close to no assessment at all.
If you want a free, structured starting point, HHS publishes a Security Risk Assessment (SRA) Tool aimed at small and medium practices. It walks you through the questions and helps you produce documentation. It’s a legitimately useful on-ramp, with one honest caveat we’ll come back to: the tool guides the work, but it does not do the thinking for you.
A plausible Tuesday at a small practice¶
A three-provider physical therapy clinic gets a renewal questionnaire from its cyber-insurance carrier. One line asks: “Have you completed a HIPAA Security Risk Assessment within the last 12 months?” The office manager checks the compliance binder a consultant sold them two years ago, finds a tab labeled “Risk Assessment,” and confidently answers yes.
Inside that tab is a checklist. Antivirus: yes. Firewall: yes. Password policy: yes. Encryption: yes. Every box ticked. It looks thorough. What it never did was inventory where patient data actually lives. And in the two years since, the clinic added a text-based appointment-reminder service, started emailing exercise plans to patients from a staff member’s phone, and moved its backups to a personal cloud account a since-departed office assistant set up. None of those are in the binder. None have a Business Associate Agreement. Nobody assessed the risk of any of them, because the “risk assessment” was a list of things someone else decided to check, frozen in time.
Then a laptop gets stolen from a car. It has cached patient records and it isn’t encrypted, a fact the real inventory would have caught and the checklist never asked about in a way that matched reality. Now the clinic is facing a breach notification, an insurance claim, and eventually a request from OCR: show us your risk analysis. They hand over the checklist. The investigator’s question is simple and devastating: where in here did you assess the risk to the data on that laptop, on that phone, in that personal cloud account? The honest answer is nowhere. The box was ticked. The work was never done.
No sophisticated attacker. No exotic vulnerability. Just a checklist standing in for an assessment, and a practice that believed it was compliant because a form said so.
The common ways practices get it wrong¶
The failures are predictable, which is good news, because predictable problems are preventable ones. These are the patterns that come up most.
- Mistaking a checklist or policy binder for the analysis. The big one, covered above. If the “risk assessment” in your files is a list of controls with no data inventory and no likelihood-and-impact analysis, you have a checklist wearing a risk assessment’s name tag.
- Only assessing the EHR. Your electronic health record is usually your best-protected system. The risk lives in the messy edges: email, texts, personal phones, spreadsheets, scanning apps, backups, and vendors. An assessment that stops at the EHR has skipped where breaches actually happen.
- Doing it once and never again. A risk assessment from the year you opened, describing systems you’ve since replaced, does not reflect current risk. If it isn’t dated within the last year or so, or hasn’t been touched since a major change, treat it as stale.
- Running the HHS SRA Tool on autopilot. The tool is good, but it will happily produce a document full of shallow or inaccurate answers if you feed it shallow or inaccurate answers. “Accurate and thorough” is on you, not the software.
- No remediation plan. Finding risks and then doing nothing about them can be worse than not looking, because now there’s a dated document showing you knew. The analysis is supposed to drive action; write down what you’ll fix and when.
- No documentation you can actually produce. “We talked about it at a staff meeting” is not an assessment. If you can’t hand an investigator or an underwriter a dated written document, functionally you don’t have one.
What to actually do¶
You do not need to panic, and you do not need to spend a fortune. You need to do the real version of the work, once, properly, and then keep it current. Here’s the honest sequence.
Start by inventorying where your ePHI lives, room by room and app by app. Walk your actual workflow: how does a patient’s information enter your practice, where does it get stored, who touches it, where does it go, where are the backups? Write down every system and every vendor. This single step surfaces most of the risk on its own.
Then, for each place data lives, name the realistic threats and your current safeguards, and rate each risk by how likely and how damaging it would be. Be honest rather than flattering; the point is to find the soft spots before someone else does. Turn the significant ones into a written remediation plan with owners and dates: encrypt the laptops, get the missing BAAs signed, move the backups off the personal account, kill the shared login. Then document the whole thing, date it, and store it where you can retrieve it in six years.
Finally, put it on a calendar. Revisit the assessment at least annually and any time something material changes. If you use the HHS SRA Tool, treat it as a structured interview, not an autopilot, and make sure the answers reflect your practice as it actually operates today.
A Security Risk Assessment checklist¶
Yes, a checklist, and here’s the irony worth sitting with: a checklist is a fine tool for confirming you did the assessment. It’s just not the assessment itself. Use this to sanity-check whether what’s in your files would actually satisfy the requirement.
Question Yes? Current (12 mo)?
────────────────────────────────────────────────────────── ──── ───────────────
Written document titled/serving as a risk analysis [ ] [ ]
Inventory of EVERY place ePHI lives (not just the EHR) [ ] [ ]
- EHR, billing, email, texts, cloud, phones, laptops [ ] [ ]
- Backups and every vendor that stores data [ ] [ ]
Threats + vulnerabilities identified for each system [ ] [ ]
Current safeguards documented for each system [ ] [ ]
Likelihood AND impact rated for each risk [ ] [ ]
Risk levels assigned [ ] [ ]
Written remediation plan with owners and dates [ ] [ ]
Dated, and retained (six-year records) [ ] [ ]
Reviewed after any major change (new EHR, location, vendor) [ ] [ ]
A “no” on the first two lines is the loud one. If you don’t have a written document, or it doesn’t inventory where your data actually lives, then whatever is in your binder is not the assessment HIPAA requires, no matter how many other boxes are checked. Fix those first.
Where to start if this feels like a lot¶
None of this is technically difficult, but it is real work, and it is exactly the kind of task that stays at the bottom of a busy owner’s list until an insurer, a referral partner, or a breach forces the issue. If you take one thing from this post, let it be this: a ticked checklist is not a risk assessment, and believing otherwise is a false sense of safety that costs the most at the worst possible moment.
This is the kind of thing we help small practices with directly. If you want a genuine Security Risk Assessment (the real inventory-and-analysis version) or you just want someone to look at the document already in your binder and tell you honestly whether it would hold up, that’s a service we offer, and we’ll produce documentation you can actually hand to an auditor or an underwriter. If you’d rather start on your own, the free HHS SRA Tool is a fair place to begin.
And if you’re simply unsure where you stand (maybe an insurer asked you that “risk assessment in the last 12 months” question and you’re not certain your answer is true), email support@breachsecurity.io and tell us what you do and how many people are on staff. We’ll tell you what you actually need, even when the honest answer is “less than you feared.”