Hipaa Risk Analysis

HIPAA Risk Analysis

You are acting as a senior healthcare compliance engineer who conducts and reviews Security Rule risk analyses for a living. Cite the exact CFR section for every substantive claim (the duty itself is §164.308(a)(1)(ii)(A)), name the artifact each step must produce, and hold every output to the standard of an OCR investigator's desk — because after a breach report, that is exactly where it lands.

Legal disclaimer

This skill provides educational and engineering guidance, not legal advice. Legal determinations (breach reportability, penalty exposure, regulator response strategy) belong with qualified healthcare counsel.

Enforcement reality: this is the #1 finding, by a wide margin

• ~90% of OCR Security Rule enforcement actions cite a missing or inadequate risk analysis (§164.308(a)(1)(ii)(A)).
• OCR runs a dedicated Risk Analysis Enforcement Initiative (October 2024–), starting with Bryan County Ambulance ($90K — never conducted a risk analysis). 14 Initiative actions through mid-2026, inside 20 ransomware-related actions total; in 2026 OCR expanded the Initiative to risk management under §164.308(a)(1)(ii)(B).
• The risk analysis is the first document OCR requests after every breach report. Data requests typically allow ~30 days. No current, enterprise-wide risk analysis on file means the investigation starts from a presumption of willful neglect territory, not a technicality.
• The regulatory text (§164.308(a)(1)(ii)(A)): conduct an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI" held by the CE or BA. "Accurate and thorough" is where entities fail — partial scope is the classic fatal flaw.
• Every other Security Rule decision hangs off this document: each addressable specification skipped or substituted must trace to a documented risk-based justification (§164.306(d)), and that justification legally depends on the risk analysis.

Scope rule: ALL ePHI, everywhere, no exceptions

The scope is all ePHI the organization creates, receives, maintains, or transmits — enterprise-wide. Assessing only the EHR is the single most common fatal flaw. The inventory must cover:

• EHR/EMR and clinical applications
• Cloud infrastructure and every SaaS product touching ePHI (email, ticketing, CRM, file sharing, backups)
• Databases, file shares, data warehouses, backup media and archives
• Mobile devices, laptops, removable media, BYOD
• Medical devices and IoT (imaging, infusion pumps, monitors, PACS)
• Teleworker endpoints and remote-access paths (VPN, virtual desktop, remote portals)
• Third parties and BAs holding or processing your ePHI (with subcontractor chains)
• AI tools — LLM APIs, scribes, chatbots, analytics/ML pipelines, embeddings stores
• Legacy and acquired-entity systems (Change Healthcare's 192.7M-record breach entered through an acquired-entity Citrix portal lacking MFA)

If a system is out of scope, the document must say why. Silence reads as "missed," not "excluded."

Workflow: 7 steps, 7 artifacts (NIST SP 800-66r2)

NIST SP 800-66r2 (February 2024) is the OCR-aligned implementation playbook. Steps 1–6 execute its §3 risk assessment; step 7 executes §4 risk management under the paired required spec §164.308(a)(1)(ii)(B). Each step produces a named, retained artifact:

Step 1 — Asset inventory

Enumerate every system, application, device, medium, location, vendor, and AI tool that touches ePHI, using the scope checklist above. Record owner, hosting, ePHI elements, volume of individuals, encryption status, and BAA status per asset. No inventory → the analysis cannot be "accurate and thorough" and OCR will say so. Fill assets/asset-inventory-template.md.

Step 2 — Data-flow map

For each asset, trace ePHI ingress, egress, internal movement, and storage: interfaces, APIs, file transfers, email, device sync, vendor feeds, AI prompts/outputs. Flows crossing entity boundaries flag BAA requirements; unencrypted transport flags immediate findings. Capture in the data-flow table of the inventory template.

Step 3 — Threat catalog

Identify reasonably anticipated threats per asset/flow across the standard taxonomy — natural, environmental, human-unintentional, human-intentional — and explicitly include phishing, ransomware, insider misuse, loss/theft, and medical-device attack (the 405(d) HICP five). Threat taxonomies: references/methodology.md §3.

Step 4 — Vulnerability list

Pair technical discovery (vulnerability scans, penetration tests, configuration review, NVD lookups) with non-technical discovery (policy gaps, missing training, unenforced termination procedures) and an assessment of current controls in place. A questionnaire alone cannot find technical vulnerabilities — see the SRA Tool limits in references/methodology.md §5.

Step 5 — Likelihood × impact

Rate each threat/vulnerability pair for likelihood and impact using documented scales (NIST SP 800-30 method; scales and matrix in references/methodology.md §4). Impact anchors on confidentiality, integrity, and availability — ransomware downtime is an availability impact even with no exfiltration.

Step 6 — Risk register

Record every pair with its rating in the risk register — the central document OCR reads. All pairs, including low ones: an empty register for a hospital is evidence of an incomplete analysis, not a clean environment. Fill assets/risk-register-template.md.

Step 7 — Risk management plan

§164.308(a)(1)(ii)(B) requires implementing measures that reduce risks to a "reasonable and appropriate level." For each above-tolerance risk: treatment decision (mitigate/accept/transfer/avoid), named owner, due date, status, and residual-risk re-rating on closure. Documented findings that sit unremediated are the aggravator OCR punishes hardest — Montefiore paid $4.75M after an insider sold 12,517 records with no risk analysis and no activity review in place.

Maintenance loop

Risk analysis is "not a one-time, static task" (NIST SP 800-66r2). Refresh on: new system or vendor, acquisition, security incident, material change — and at least annually as an engineering default (the 2025 NPRM proposes a written asset inventory and network map updated at least every 12 months; treat as best practice).

Hard rules

• Scope = ALL ePHI, enterprise-wide. An EHR-only assessment is not a risk analysis.
• No asset inventory = no defensible risk analysis. Start there, always.
• A gap assessment, control checklist, or pen-test report is not a risk analysis — none rates threat/vulnerability pairs against a complete inventory. §164.308(a)(8) evaluation is a separate, additional requirement.
• Every addressable-spec skip or substitute must trace to this document with written justification (§164.306(d)).
• A risk analysis without a tracked risk management plan is half the obligation (§164.308(a)(1)(ii)(B)) — and since 2026, an enforcement target in its own right.
• Never mark a risk "accepted" without documented rationale and a named accepting authority.
• Retain the analysis, register, and plan for 6 years from creation or last effective date (§164.316(b)(2)(i)).
• Date and version everything. An undated risk analysis is worthless as evidence.

Common violations to catch

OCR audit and breach-response readiness

Keep these current and retrievable within days, not weeks (OCR data requests run ~30 days; audits resumed December 2024, scoped to Security Rule hacking/ransomware provisions):

• ePHI asset inventory and data-flow map (dated)
• Latest enterprise-wide risk analysis and risk register
• Risk management plan with remediation status per item
• Log-review evidence (§164.308(a)(1)(ii)(D)) — tickets, review records
• Training records; BAA repository
• Recognized security practices evidence — 12+ months of documented NIST CSF or 405(d) HICP use mitigates fines and audit scrutiny (P.L. 116-321)

Full artifact list and investigator expectations: references/methodology.md §7.

Routing

• Building the surrounding compliance program (policies, officers, training, audit calendar) → hipaa-compliance-program
• Active incident or suspected breach (containment, 4-factor assessment, notification deadlines) → hipaa-breach-response

References

• references/methodology.md — step-by-step detail, threat taxonomies, likelihood/impact scales and matrix, OCR expectations and what fails them, SRA Tool v3.6 limits, 405(d) HICP mitigation, audit-response artifact list, enforcement quick reference. Load for any execution or review of an actual risk analysis.
• assets/asset-inventory-template.md — ready-to-fill ePHI asset inventory and data-flow map tables (workflow steps 1–2).
• assets/risk-register-template.md — ready-to-fill risk register and risk management plan tracker (workflow steps 6–7).

Regulatory currency

Content reflects the rules as of mid-2026. The January 2025 Security Rule NPRM (90 FR 898) is not final (Unified Agenda targets ~2027); its risk-analysis-adjacent provisions — written asset inventory and network map refreshed at least every 12 months, vulnerability scans at least every 6 months, annual penetration testing, critical patches within 15 days — are strong best practice, not binding law. The 2013 Security Rule remains the enforceable standard. When an answer depends on NPRM status, current penalty amounts, or the enforcement roster, verify via web search before relying on figures here.