How to Conduct a HIPAA Risk Analysis: A Step-by-Step Guide for Healthcare Organisations

Author: Eunoia Consulting Co. | Published: May 13, 2026

A practical, step-by-step guide to conducting a HIPAA risk analysis — the single most commonly cited deficiency in OCR enforcement actions. Covers scope, methodology, documentation, and risk management planning.

Key Takeaways

  • A HIPAA risk analysis is legally required under the Security Rule — not optional — and must be documented, comprehensive, and repeated regularly.
  • Risk analysis scope must include all systems that create, receive, maintain, or transmit ePHI — including AI tools and cloud platforms.
  • Likelihood and impact ratings must be assigned to each identified threat and vulnerability, not just catalogued.
  • AI-specific threats — model inversion, prompt injection, data poisoning — must now be included in every healthcare risk analysis.
  • OCR enforcement actions consistently cite inadequate risk analysis as the root cause of HIPAA penalties.

Why the HIPAA Risk Analysis Is the Foundation of Compliance

If there is one HIPAA requirement that healthcare organisations consistently fail to meet — and that the Office for Civil Rights (OCR) consistently cites in enforcement actions — it is the risk analysis. The HIPAA Security Rule at 45 CFR § 164.308(a)(1) 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 all electronic protected health information (ePHI) they create, receive, maintain, or transmit.

This is not a one-time exercise. It is an ongoing process that must be updated whenever significant changes occur to your environment, systems, or operations — and reviewed at least annually.

The OCR's guidance makes clear that a risk analysis is the prerequisite for all other HIPAA Security Rule compliance. Without it, you cannot know what safeguards are appropriate, and you cannot demonstrate that your security programme is reasonable and appropriate for your specific environment.

What a HIPAA Risk Analysis Must Cover

The OCR's guidance on risk analysis identifies nine required elements:

  • Scope: The analysis must cover all ePHI that the organisation creates, receives, maintains, or transmits — regardless of the medium or system in which it resides.
  • Data collection: Identify where ePHI is stored, received, maintained, or transmitted.
  • Identify and document potential threats and vulnerabilities: Threats are natural, human, or environmental forces that could exploit vulnerabilities; vulnerabilities are flaws or weaknesses that could be exploited.
  • Assess current security measures: Document existing controls and evaluate their effectiveness.
  • Determine the likelihood of threat occurrence: Assess how likely each identified threat is to exploit each identified vulnerability.
  • Determine the potential impact: Assess the magnitude of harm that could result from each threat/vulnerability combination.
  • Determine the level of risk: Combine likelihood and impact to produce a risk level for each threat/vulnerability pair.
  • Finalise documentation: Produce a written risk analysis document.
  • Periodic review and updates: Review and update the risk analysis in response to environmental or operational changes.
  • Step-by-Step: Conducting Your HIPAA Risk Analysis

    Step 1: Define the Scope

    Begin by defining the boundaries of your risk analysis. The scope must include all systems, applications, devices, and locations where ePHI is created, received, maintained, or transmitted. This includes:

  • EHR and practice management systems
  • Medical devices that collect or transmit patient data
  • Billing and revenue cycle systems
  • Email and communication platforms used for ePHI
  • Cloud storage and collaboration tools
  • Mobile devices used by staff
  • Third-party systems accessed by business associates
  • Physical locations where ePHI is accessed or stored
  • A common scoping error is limiting the analysis to "IT systems" while overlooking medical devices, portable media, and remote access scenarios. The OCR expects a comprehensive scope.

    Step 2: Inventory Your ePHI

    For each system and location in scope, document:

  • What ePHI is stored, processed, or transmitted
  • The volume and sensitivity of the ePHI
  • Who has access to the ePHI
  • How the ePHI flows between systems and locations
  • What technical, administrative, and physical safeguards currently protect it
  • This inventory is the foundation of your risk analysis and should be maintained as a living document.

    Step 3: Identify Threats and Vulnerabilities

    For each ePHI asset identified in Step 2, identify the threats that could cause harm and the vulnerabilities that could be exploited. Threats fall into three categories:

    Natural threats: Floods, fires, earthquakes, power outages, and other environmental events that could damage systems or disrupt access to ePHI.

    Human threats: Both intentional (malicious insiders, external attackers, social engineering) and unintentional (accidental deletion, misconfiguration, lost devices) human actions that could compromise ePHI.

    Environmental threats: Hardware failures, software bugs, network outages, and other technical failures that could affect ePHI availability or integrity.

    For each threat, identify the vulnerabilities it could exploit. Common vulnerabilities include:

  • Unpatched software and operating systems
  • Weak or shared passwords
  • Lack of multi-factor authentication
  • Inadequate access controls
  • Unencrypted devices or data in transit
  • Insufficient audit logging
  • Inadequate staff training
  • Weak vendor management practices
  • Step 4: Assess Current Security Measures

    For each threat/vulnerability pair, document the existing controls that mitigate the risk. Be honest about the effectiveness of existing controls — overestimating control effectiveness is a common error that leads to underestimating residual risk.

    Controls to assess include:

  • Technical controls (encryption, access controls, audit logging, intrusion detection)
  • Administrative controls (policies, training, workforce management, vendor management)
  • Physical controls (facility access controls, workstation security, device management)
  • Step 5: Determine Likelihood and Impact

    For each threat/vulnerability pair, assign a likelihood rating and an impact rating. The OCR does not prescribe a specific methodology, but a simple three-level scale (High/Medium/Low) is commonly used and defensible.

    Likelihood reflects the probability that a given threat will exploit a given vulnerability, taking into account existing controls. Factors to consider include:

  • The motivation and capability of potential threat actors
  • The attractiveness of your ePHI to potential attackers
  • The effectiveness of existing controls
  • Historical incident data
  • Impact reflects the magnitude of harm that would result if the threat successfully exploited the vulnerability. Factors to consider include:

  • The volume and sensitivity of ePHI at risk
  • The potential for patient harm
  • Financial consequences (regulatory penalties, breach notification costs, reputational damage)
  • Operational disruption
  • Step 6: Determine Risk Levels

    Combine likelihood and impact to produce an overall risk level for each threat/vulnerability pair. A simple risk matrix approach works well:

    | | Low Impact | Medium Impact | High Impact | |---|---|---|---| | High Likelihood | Medium | High | Critical | | Medium Likelihood | Low | Medium | High | | Low Likelihood | Low | Low | Medium |

    Document the risk level for each identified risk, along with the rationale for your assessment.

    Step 7: Document and Prioritise

    Compile your findings into a written risk analysis document. This document should include:

  • Executive summary
  • Scope definition
  • ePHI inventory
  • Threat and vulnerability catalogue
  • Current control assessment
  • Risk register (likelihood, impact, risk level for each identified risk)
  • Prioritised list of risks requiring remediation
  • The risk register becomes the foundation for your risk management plan.

    Step 8: Develop a Risk Management Plan

    The risk analysis itself is not sufficient — the Security Rule also requires a risk management plan that implements security measures to reduce identified risks to a reasonable and appropriate level. Your risk management plan should:

  • Prioritise risks for remediation based on risk level
  • Assign ownership for each remediation action
  • Define target completion dates
  • Specify the security measures to be implemented
  • Document the rationale for accepting any residual risks
  • Step 9: Review and Update

    The risk analysis is not a one-time exercise. It must be reviewed and updated:

  • At least annually
  • Following significant changes to your environment (new systems, new locations, mergers, acquisitions)
  • Following a security incident or breach
  • When new threats emerge (e.g., a new ransomware campaign targeting healthcare)
  • Common Risk Analysis Mistakes

    Scope too narrow: Limiting the analysis to the EHR while overlooking medical devices, email, mobile devices, and third-party systems.

    Treating it as a checklist: A risk analysis is not a compliance checklist — it requires genuine assessment of your specific environment, not generic responses.

    Overestimating control effectiveness: Documenting controls that exist on paper but are not consistently implemented or monitored.

    No risk management follow-through: Conducting a risk analysis but failing to implement a risk management plan to address identified risks.

    Infrequent updates: Treating the risk analysis as a one-time project rather than an ongoing programme.

    > "The OCR does not expect perfection — it expects a genuine, documented effort to understand and manage risk. A well-documented risk analysis that identifies real risks and drives real remediation is far more defensible than a polished document that does not reflect operational reality."

    How Eunoia Consulting Can Help

    Eunoia Consulting Co. provides HIPAA risk analysis services for healthcare organisations of all sizes. Our approach combines regulatory expertise with deep operational knowledge to produce risk analyses that are both defensible and actionable.

    We also offer a Data Governance Assessment that includes HIPAA risk analysis readiness as one of six evaluated dimensions.

    Contact us to discuss your HIPAA compliance needs.


    Key Takeaways

  • The HIPAA risk analysis is the single most commonly cited deficiency in OCR enforcement actions — and the most preventable source of HIPAA liability.
  • A defensible risk analysis requires four components: asset and data flow inventory, threat and vulnerability identification, likelihood and impact assessment, and a documented risk management plan.
  • Scope is the most common risk analysis failure — organisations that limit their analysis to EHR systems while ignoring medical devices, cloud services, and business associate data flows are not compliant.
  • Risk analyses must be updated whenever there is a significant operational or environmental change — not just on an annual schedule — to maintain compliance and reflect the current threat landscape.
  • Documentation quality determines enforceability — a risk analysis that cannot be produced, explained, and defended in an audit is legally equivalent to no risk analysis at all.

A robust HIPAA risk analysis is the foundation of a compliant healthcare operation — but compliance is only one dimension of operational excellence. Eunoia Consulting Co.'s Healthcare Business Management Consulting service helps organisations build the governance, process, and management infrastructure that keeps compliance sustainable at scale. Learn more →


Once your risk analysis is complete, the next step is ensuring your AI systems meet HIPAA requirements before deployment. Read our companion guide: HIPAA AI Compliance Checklist: What Healthcare Organisations Must Do Before Deploying AI.