Back to Blog
Compliance Governance
9 min read

HIPAA Security Rule Risk Analysis: A Practical Approach

The most cited deficiency in HIPAA enforcement is a missing or inadequate risk analysis. What separates one that holds up from a vulnerability scan with a cover page.

GuardsArm Team

Security Experts

December 1, 2025

HIPAA risk analysis

Inadequate risk analysis is among the most frequently cited findings in HIPAA enforcement actions. Not because organisations skip it, but because what they produce is something else wearing its name — usually a vulnerability scan, a control checklist, or a gap assessment against a framework.

Required, not addressable
Risk analysis is a required implementation specification
45 CFR 164.308(a)(1)(ii)(A)
Enterprise-wide
Every system, location and medium holding ePHI — not a sample
Ongoing
A point-in-time document from three years ago is not a current analysis

What it is not

Not a risk analysisWhy
A vulnerability scanIdentifies technical weaknesses, not risk to ePHI. No threat, likelihood or impact
A control checklistRecords what you have, not what could go wrong
A gap assessment against NIST or HITRUSTMeasures conformance to a framework, not risk to your data
A penetration testDemonstrates exploitability of a subset, at a point in time
A BAA inventoryNecessary, and a different exercise

Each of these is useful and each is an input. None is the analysis.


The six things it must contain

1. Scope. Every system, application, device, location and medium where ePHI is created, received, maintained or transmitted. Enterprise-wide, explicitly — including medical devices, cloud services, backups, paper and third parties.

2. An ePHI inventory. Where it lives, how it flows, who can reach it. This is the step that takes the longest and the one most often abbreviated, and without it the rest is guesswork.

3. Threats and vulnerabilities, paired. A vulnerability alone is not a risk. It becomes one when paired with a threat that could exploit it. Include natural, human and environmental threats — not only cyber.

4. Current controls. What is already in place that affects likelihood or impact.

5. Likelihood and impact. Rated, with the rating criteria written down so the result is reproducible rather than an opinion.

6. Risk level, documented. The output is a rated list of risks, not a narrative.

The inventory is the part that fails
Most inadequate analyses are inadequate because the scope was never established. You cannot assess risk to data you have not located, and "the EHR" is not an inventory — the reporting database, the departmental share, the imaging archive and the transcription vendor all hold ePHI too.

Pairing threats with vulnerabilities

The structure that makes an analysis defensible:

AssetThreatVulnerabilityCurrent controlLikelihoodImpactRisk
EHR databaseMalicious insiderBroad clinical read accessAudit logging, targeted alertingMediumHighHigh
Imaging archiveExternal attackerDICOM accepts unauthenticated associationsNetwork segmentationMediumHighHigh
LaptopsTheftPortable, leave the buildingFull-disk encryptionHighLowMedium
BackupsRansomwareReachable with domain credentialsOffsite copy, not immutableMediumVery highCritical
Legacy lab systemExploitationUnpatched, end of supportIsolated VLANMediumMediumMedium

Note the laptop row. High likelihood, low impact — because encryption means a stolen laptop is probably not a reportable breach. That is how a control earns its place in the analysis, and it is why "we have encryption" belongs here rather than as a standalone assertion.


Risk analysis, then risk management

The analysis identifies risk. The risk management plan is a separate required specification and is what enforcement actually looks for: what you decided to do about each risk, who owns it, by when.

Risk analysis feeding risk managementThe analysis produces a rated list; the management plan records the decision, owner and date for each, and implementation is evidenced.Analyserated risk listDecidemitigate, transfer, acceptPlanowner and dateImplementand evidence itReassesson change or annually
An accepted risk with a named owner and a review date is defensible. The same risk undocumented is a finding.

Accepting a risk is a legitimate outcome. Accepting it silently is not.


When to redo it

Not merely annually. Trigger a reassessment on:

  • A new clinical system, or a significant change to an existing one
  • A merger, acquisition or new facility
  • A security incident
  • A new threat that materially changes likelihood
  • A change in the regulatory baseline
Date it and keep the old ones
Retain prior analyses for at least six years alongside the documentation requirement. Showing a progression of analyses over time demonstrates an ongoing process, which is precisely what is being asked for.

Where to start

If your last analysis was a scan report, start with the inventory. Spend the time locating ePHI properly — including the copies in reporting databases, non-production environments and vendor systems. Everything downstream depends on it, and it is the part an assessor will test first.

For the operational side of the same obligation, see vulnerability management.

GuardsArm conducts HIPAA Security Rule risk analyses, including the ePHI inventory work most organisations find hardest. Book a scoping call.

Written by GuardsArm Team

Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.

Take the next step on “HIPAA Security Rule Risk Analysis: A Practical Approach”

Talk to the GuardsArm team about how these services apply to your environment.