HIPAA Risk Analysis

Why HIPAA risk analysis matters

HIPAA §164.308(a)(1)(ii)(A) — the Risk Analysis implementation specification — requires covered entities and business associates to "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 or business associate." It sits at the top of the Security Management Process standard and is the foundation on which the rest of the Security Rule is built.

Everything downstream — the policies you write, the controls you deploy, the contingency plan you exercise, the sanctions you apply — should trace back to findings in the risk analysis. Without it, compliance becomes a checklist exercise divorced from actual risk. With it, limited time and budget flow to the systems and scenarios that matter most.

OCR has made the point repeatedly. In its published resolution agreements, missing or inadequate risk analyses are the single most cited finding — present in a majority of major enforcement actions from the last decade. That pattern reflects a consistent regulator view: an organization that cannot demonstrate an accurate and thorough HIPAA risk analysis has not started its compliance program.

For the broader Security Rule context, see the HIPAA Security Rule guide and the HIPAA hub page.

What "accurate and thorough" actually requires

HHS guidance — most notably the 2010 Final Guidance on Risk Analysis Requirements — defines what "accurate and thorough" means in practice. Nine elements must be addressed.

1. Scope of the analysis. Cover every system, application, and process that creates, receives, maintains, or transmits ePHI, including portable media, remote access, and third-party systems.
2. Data collection. Gather information about how ePHI is stored, received, maintained, and transmitted. This includes interviewing workforce members and reviewing documentation, not just running scans.
3. Identification and documentation of potential threats and vulnerabilities. Threats are the sources of harm — natural, human, environmental. Vulnerabilities are the weaknesses threats can exploit.
4. Assessment of current security measures. Document the controls already in place and how effectively they reduce risk.
5. Determination of the likelihood of threat occurrence. Qualitatively or quantitatively, assess how likely each threat is to materialize given current controls.
6. Determination of the potential impact of threat occurrence. Assess the consequence to confidentiality, integrity, and availability of ePHI if the threat materializes.
7. Determination of the level of risk. Combine likelihood and impact to produce a risk rating.
8. Finalized documentation. Written output that can be produced on demand.
9. Periodic review and updates. A living document, refreshed at defined intervals and after material change.

These nine elements map cleanly onto NIST Special Publication 800-30 Revision 1, which is why most HIPAA programs adopt 800-30 as their methodology.

Scope: the most common source of failure

The single most common HIPAA risk analysis failure is an incomplete scope. OCR repeatedly finds that organizations assessed the EHR, the email system, and the main file server — but not the developer laptops, the analytics warehouse, the backup tapes, the clinical tablets, the text message workflow a customer support team built on the side, or the twenty business associates whose systems jointly touch the same PHI.

A defensible scope begins with a PHI data flow map. Answer four questions for every system in the organization.

• Does this system create, receive, maintain, or transmit ePHI?
• If yes, what categories of PHI, and at what volume?
• Who else touches the data — upstream, downstream, or in parallel?
• What happens when the data leaves the system?

Every system that answers yes to the first question is in scope. Systems that currently answer no but are planned to answer yes in the next twelve months should also be captured so the analysis stays ahead of the build plan.

Threats and vulnerabilities

NIST SP 800-30 separates threats from vulnerabilities — a useful distinction that prevents the common error of treating a missing control as a threat.

Threat categories include:

• Adversarial threats — external attackers, malicious insiders, organized crime, nation-state actors.
• Accidental threats — workforce errors, misconfigured systems, mis-sent emails, lost devices.
• Structural threats — hardware failures, software bugs, vendor outages, capacity exhaustion.
• Environmental threats — fire, flood, power failure, pandemic.

For each in-scope system, inventory the threats that realistically apply and the vulnerabilities that could let those threats materialize. Industry threat intelligence, OCR enforcement patterns, and your own incident history are all valid inputs.

Likelihood and impact

Likelihood and impact can be expressed qualitatively (low, moderate, high, very high) or quantitatively (probability ranges and dollar figures). Most HIPAA programs start qualitative and tighten over time as better data becomes available.

A defensible likelihood assessment considers the threat source's motivation, capability, and opportunity; the effectiveness of current controls; and the frequency with which similar events have occurred historically in the organization's sector.

A defensible impact assessment considers the confidentiality, integrity, and availability consequences; the volume and sensitivity of PHI affected; the regulatory and contractual consequences; and the downstream effects on patients or end users.

The risk level is a function of the two, often represented in a heat map. Risks above a defined threshold feed the risk management plan required by §164.308(a)(1)(ii)(B).

Documentation that survives audit

The risk analysis artifact itself must be written, retrievable, and referenced throughout the rest of the program. A defensible artifact includes:

• Scope statement and asset inventory.
• Methodology used, with explicit reference to NIST SP 800-30 or the equivalent.
• Threat catalog and vulnerability catalog.
• Inventory of current controls.
• Likelihood and impact ratings for each risk, with rationale.
• Risk register sorted by priority, feeding the risk management plan.
• Change log documenting updates.
• Signatures or approvals from the HIPAA security official and executive leadership.

Retain for at least six years from creation or last effective date. Because this is a living document, the retention clock resets every time the artifact is updated.

Integrating risk analysis into the operating rhythm

A risk analysis that runs once and then gathers dust is the worst possible outcome — it creates a false sense of completion. Build the refresh into the operating rhythm.

• Quarterly. Review the risk register, update ratings as controls mature or threats evolve, and close risks that have been adequately mitigated.
• Annually. Run a full refresh. Revisit scope, re-interview owners, re-run threat modeling, and produce an updated artifact.
• Event-driven. Trigger a targeted refresh after a material change — new system, new customer segment, significant incident, regulatory update, organizational restructuring.

Tie the refresh cadence to the contingency planning test calendar and the compliance checklist review calendar so the full program moves together.

How this fits into your HIPAA program

The risk analysis is the connective tissue of a HIPAA program. It sets priorities for the HIPAA Security Rule controls you invest in. It shapes the risk management plan at §164.308(a)(1)(ii)(B). It informs the testing calendar for contingency planning. It surfaces the scenarios that workforce training should address. It feeds the threat scenarios your incident response runbooks rehearse. And it anchors the conversation with customers and regulators when they ask how you prioritize your compliance program.

Common pitfalls

• Scope gaps. The analysis covers the obvious systems and misses the edges — developer laptops, shadow IT, analytics warehouses, third-party SaaS with ad hoc BAAs.
• Vulnerability scan as risk analysis. A pen test report or a CVE scan gets stapled to a cover page and labeled a risk analysis. OCR has rejected this pattern consistently.
• Generic threat catalog. The threat list is a copy of a consultant template with no tailoring to the organization's actual technology and workforce.
• No likelihood or impact reasoning. Risks are rated "high" or "medium" with no written justification, so the ratings are not defensible a year later.
• Artifact from two years ago. The risk analysis on file predates significant changes in the environment, and the change log is empty.
• No linkage to the risk management plan. Risks are identified but not prioritized, and there is no mitigation plan tied to the register.
• Single-person exercise. The security officer wrote the risk analysis alone, without input from engineering, operations, clinical, or legal. Gaps are inevitable.
• Business associates excluded. Risks the organization inherits from its BAAs are missing, even though OCR has made clear those risks are in scope.

How episki helps

episki brings HIPAA risk analysis into the same workspace as the rest of your compliance program. The risk register is linked to assets, controls, and policies; scope is refreshed automatically as systems are added to inventory; threat and vulnerability catalogs are pre-built and tailored to healthtech; likelihood, impact, and rationale are captured in structured fields that survive personnel changes; and the annual refresh runs as a guided workflow with evidence rolling up for auditors and customers.

See the full HIPAA platform overview or start a free trial from the top of the hub page.