A security risk analysis is the foundation every other safeguard rests on. The HIPAA Security Rule requires an accurate and thorough assessment of the risks to electronic protected health information (ePHI), and it is the single most commonly cited finding when practices fall short — not because the controls were missing, but because no one ever systematically asked where the risks were. For an EMR administrator, the risk analysis is what turns a pile of disconnected security settings into a defensible, prioritized program. It is also a recurring obligation, not a one-time project: a risk analysis from three years ago, before you moved to the cloud or added a telehealth platform, no longer describes your environment. Here is how to run one you can actually stand behind.
Understand what the requirement actually asks
The Security Rule's risk-analysis standard at 45 CFR 164.308(a)(1) requires you to identify the risks and vulnerabilities to the confidentiality, integrity, and availability of all the ePHI you create, receive, maintain, or transmit. That last phrase is the part practices underestimate: it is not just the EMR database. It is the backups, the interface engine, the laptops, the phones with the in-basket app, the cloud vendor, and the lab feed. NIST frames this as a structured process — characterize the system, identify threats and vulnerabilities, determine likelihood and impact, and rate the resulting risk — rather than an informal walkthrough. Treating it as a defined methodology is what makes the result repeatable and auditable.
Scope the ePHI first
You cannot assess risk to data you have not located. Before rating anything, inventory where ePHI lives and how it moves.
| Location / flow | Examples to inventory |
|---|---|
| At rest | EMR database, backups, archives, scanned-document store |
| In transit | Lab/billing interfaces, FHIR APIs, portal, email |
| Endpoints | Workstations, laptops, tablets, phones, printers/scanners |
| Third parties | Cloud host, clearinghouse, telehealth vendor, business associates |
This inventory is half the work and the half most often skipped. An honest map of where ePHI rests, where it travels, and who else touches it routinely surfaces surprises — a forgotten archive, an export folder on a shared drive, a vendor connection nobody documented. Each of those is a place a risk can hide, and you cannot rate a risk you have not found.
Identify threats and vulnerabilities
For each location, pair the realistic threats with the vulnerabilities that would let them cause harm. A threat is the potential source of trouble; a vulnerability is the weakness it could exploit. Ransomware (threat) matters because of an unpatched, internet-exposed server and backups on the same network (vulnerabilities). Employee snooping (threat) matters because record-level audit logs are not reviewed (vulnerability).
- Consider threats across categories: malicious actors, human error, insider misuse, and environmental or technical failure.
- Map each threat to the specific weaknesses in your environment that would let it succeed.
- Pull from what you already know — prior incidents, audit findings, vendor advisories, and CISA alerts relevant to healthcare.
- Do not theorize in the abstract; tie every threat to the actual ePHI locations you inventoried.
Rate likelihood and impact
Use a consistent scale across every finding so the ratings are comparable. A high-likelihood, high-impact risk — say, an unpatched system reachable from the internet that holds your whole database — belongs at the top of the list regardless of how hard it is to fix. Resist the temptation to quietly downgrade a serious risk because the remediation is inconvenient; the rating should reflect the danger, and the difficulty belongs in the remediation plan, not the score.
Turn findings into a remediation plan
A risk analysis that ends in a list of risks is only half done. The Security Rule expects risk management — reducing risks to a reasonable and appropriate level — to follow. Convert each significant finding into a tracked action with an owner and a target date.
- Prioritize by risk rating, addressing high-likelihood, high-impact items first.
- Assign each remediation an owner and a realistic deadline, and record the decision.
- Where you accept a risk rather than remediate it, document the rationale and who approved it.
- Track remediation to closure and feed the results back into the next assessment.
Keep it current and documented
The risk analysis is not an annual ritual you file and forget. Revisit it when something material changes — a new EMR module, a move to the cloud, a new interface or vendor, or a security incident — and on a regular cadence in between. HHS and ONC offer guidance and a Security Risk Assessment (SRA) Tool aimed at smaller practices, and NIST's risk-assessment and HIPAA Security Rule publications provide the underlying method. Whatever tool you use, keep the documentation: the scope, the findings, the ratings, the decisions, and the remediation history. That record is both the engine of your security program and the evidence that it genuinely operates, and it is exactly what an investigator will ask to see first.