Most independent practices learn about the security risk assessment requirement one of three ways: a MIPS attestation asks about it, a cyber insurance application asks about it, or a breach happens and an OCR investigator asks for it. The third way is the expensive one.
Here’s what the requirement actually says, what a real assessment covers, how the free government tool works, the mistakes that make an assessment worthless, and what a practice can hand to an IT partner versus what has to stay in house. This is IT guidance from a provider that does this work, not legal advice, so run compliance questions past your healthcare attorney or compliance consultant.
Is a security risk assessment really required?
Yes, and this is worth being precise about because “HIPAA compliant” gets thrown around loosely. The HIPAA Security Rule, at 45 CFR 164.308(a)(1)(ii)(A), requires every covered entity to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.” That’s a required implementation specification, not an addressable one. There is no small-practice exemption.
The rule doesn’t state a literal frequency. It requires the analysis to be current and to be revisited as the environment changes, and HHS guidance describes risk analysis as an ongoing process rather than a one-time event. In practice, an annual refresh is the cadence auditors, insurers, and MIPS attestations expect, with an additional update after any significant change: a new EHR, a cloud migration, a new location, a merger, a security incident.
The enforcement record is where this stops being abstract. When the HHS Office for Civil Rights investigates a reported breach, the risk analysis is among the first documents requested, and a missing, outdated, or superficial one is one of the most frequently cited failures across OCR’s published enforcement actions. OCR’s own Security Rule guidance material is explicit that risk analysis is the foundation of a security program. A practice that has never done one isn’t slightly behind on paperwork. It’s missing the document the entire investigation pivots on.
What does the assessment actually cover?
Strip away the compliance vocabulary and a risk analysis answers five questions in order. Each one produces something written.
Where does ePHI live and move? Every system, device, and pathway that stores or touches electronic patient information: the EHR and practice management system, imaging systems, email, workstations, laptops, phones, backup destinations, cloud services, and the vendors data flows to. Practices are consistently surprised by this inventory. The EHR is obvious; the front-desk PC with exported billing spreadsheets, the provider’s personal phone with work email, and the old server in the closet are the entries that matter.
What could go wrong? For each place ePHI lives, the realistic threats: ransomware and phishing, stolen or lost devices, a departed employee whose account still works, a vendor breach, hardware failure, fire or flood taking out the only copy of something. This doesn’t require imagination so much as honesty. Healthcare is a top ransomware target precisely because attackers know what practice data is worth.
What protects it today? The current safeguards, documented as they actually are, not as everyone assumes they are. Is MFA enforced on email or just available? Are laptops actually encrypted, and can you produce a report proving it? Do backups run, and has anyone restored from one? The gap between assumed and verified is where most findings come from.
How bad is each gap? Each identified risk gets ranked, typically by likelihood and impact. An unencrypted laptop that travels between clinic sites is high on both axes. A rarely used system with no ePHI is low. The ranking is what turns a long scary list into a workable sequence.
What’s the plan? A written remediation plan: each significant risk, the fix, who owns it, and a target date. This is the piece that makes everything above it meaningful, and it’s the piece OCR looks for evidence of. Identifying a risk in 2024 and doing nothing about it by 2026 is a worse position than never having found it, and it’s a documented one.
All five outputs go into a dated document the practice keeps. HIPAA documentation retention runs six years, so the assessment, and each year’s refresh, becomes part of a growing file that shows a program operating over time.
What is the HHS SRA Tool and should a small practice use it?
HHS and the Office of the National Coordinator publish a free application called the Security Risk Assessment Tool, built specifically for small and medium practices. It’s a downloadable Windows application (with a paper version available) that walks you through multiple-choice questions across the Security Rule’s areas, lets you record threats and safeguards, and produces a report you keep as documentation.
It’s genuinely useful and the price is right. Two honest caveats. First, the tool is only as good as the answers, and the questions assume someone can accurately state how encryption, access control, audit logging, and backups are configured in your environment. In a practice with no technical staff, that person may not exist, and guessed answers produce a document that reads fine and proves nothing. Second, the tool ends where the real work begins: it identifies the gaps but doesn’t close them. A completed SRA Tool report with a list of unaddressed high risks and no remediation activity is not a strong position.
A workable division for many practices: use the SRA Tool as the framework, have your IT partner supply verified technical answers and evidence, and let the practice’s leadership own the risk decisions and the remediation budget.
What do practices get wrong?
The same assessment failures repeat across practices, and they’re worth naming because each one produces a document that looks like compliance and functions like none.
One and done. The assessment from the EHR go-live in 2019, never touched since. Environments drift, staff turn over, threats change, and an analysis describing a network you no longer run demonstrates the opposite of an ongoing program. The refresh is the requirement’s real substance.
Checkbox answers without verification. “Yes, data is encrypted” written down because it sounds right. When an investigator, or a breach, tests the answer, the gap between attested and actual becomes the finding. Every yes in the assessment should trace to something checkable: a policy export, a device report, a restore log.
No documentation at all. Some practices have genuinely decent security and no written analysis behind it. Under the Security Rule that’s still a failure, because the requirement is the documented assessment, not just the safeguards. If it isn’t written down and dated, it didn’t happen as far as an audit is concerned.
Scope that stops at the EHR. The EHR vendor’s assurances cover the EHR. Your risk analysis covers everything else: workstations, email, phones, backups, the Wi-Fi, the billing service, the answering service. Most practice breaches start outside the EHR, usually in email.
A findings list with no follow-through. Ranked risks, no owners, no dates, no evidence anything changed. The remediation plan and its execution are what distinguish a security program from a self-incrimination exercise.
The practical checklist
Run this as the working sequence for an assessment. A practice of 10 to 50 people can complete it in weeks, not months, and the annual refresh is far faster than the first pass.
| # | Step | Output to keep |
|---|---|---|
| 1 | Inventory every system, device, and service that stores or touches ePHI, including personal devices and cloud services | Written ePHI inventory |
| 2 | List the vendors ePHI flows to and confirm a signed BAA exists for each | BAA file, gaps flagged |
| 3 | Document current safeguards with evidence: MFA enforcement, encryption status reports, access lists, backup and restore logs, training records | Evidence folder, dated |
| 4 | Identify realistic threats to each inventory item: ransomware, lost devices, stale accounts, vendor failure, disaster | Threat list per system |
| 5 | Rank each risk by likelihood and impact | Risk register |
| 6 | Write the remediation plan: fix, owner, target date for each significant risk | Remediation plan |
| 7 | Have practice leadership review and sign off on the risks accepted and the fixes funded | Signed, dated assessment |
| 8 | Execute the plan and record completion evidence as items close | Updated register |
| 9 | Calendar the annual refresh, plus a trigger review for any major change or incident | Recurring date, named owner |
Steps 7 and 9 are the ones that most often go missing, and they’re the two that convert a document into a program.
What can an MSP do, and what stays with the practice?
An IT partner can carry most of the technical weight: building the inventory, pulling the evidence that proves what’s actually configured, identifying gaps a non-technical reader would miss, executing the remediation, and regenerating current documentation each year so the refresh is routine instead of archaeology. If the assessment surfaces the usual findings, unenforced MFA, unverified backups, unencrypted devices, missing endpoint detection, those fixes are standard managed cybersecurity work. The broader safeguard picture the assessment feeds into is covered in our guide to HIPAA IT requirements for medical practices, and the backup piece specifically in how practices should back up EHR, imaging, and Microsoft 365 data.
What stays with the practice is ownership. The covered entity is the practice, so the practice reviews the findings, decides which risks to fix and which to formally accept, funds the plan, and signs the document. A physician owner can’t delegate that signature, but with a prepared partner it’s an hour of review, not a research project. The same split applies to policies and training: an MSP can draft and deliver, but the practice adopts and enforces.
One more division worth stating: we support the environment your EHR and practice management systems run on, the servers or hosting, workstations, network, backups, and access, and we coordinate with your software vendors when a finding sits inside their application. The assessment covers that whole environment either way.
Braintek has supported Texas businesses since 2002, with local teams in Houston and Dallas–Fort Worth. We run fully managed IT for practices of roughly 10 to 50 people and co-managed support alongside internal IT for larger organizations, we sign business associate agreements, and risk assessment documentation is part of the ongoing service rather than an annual surprise invoice. How that looks day to day is on our healthcare IT page, with a dedicated page for independent medical practices, and if you’re weighing providers, our guide to choosing an MSP for a medical practice covers the questions to ask.
If your practice has never done a documented risk analysis, or the last one predates your current systems, the distance to fixed is shorter than it feels. Schedule a discovery call and tell us where things stand. The first conversation is about your inventory and your last assessment date, and it usually tells you within fifteen minutes how much work actually sits between you and a signed, current document.