How to Conduct a HIPAA Risk Analysis in 2026

Conducting a Security Risk Analysis (SRA) in 2026 is not just an item to check off the box each year—it is the backbone of your security program and a central expectation of federal regulators. The HIPAA Security Rule explicitly requires covered entities and business associates to perform "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI)."[1] With the ever-expanding cyber threats and increased use of AI, this assessment must be more intentional, systematic, and continuous than ever before.

Below is a step‑by‑step guide to conducting a Security Risk Analysis in 2026, built around seven core steps of a HIPAA risk assessment process and grounded in official HHS/OCR and ONC guidance.

Why a Security Risk Analysis Is Crucial in 2026

OCR has been clear for years: the security risk analysis is foundational to compliance with the HIPAA Security Rule. It is the first step in identifying and implementing safeguards that are "reasonable and appropriate" for your specific environment, size, and complexity. Without it, you cannot credibly claim that your technical, physical, and administrative controls address your risks.

These key reasons are why an SRA is critical now:

• Regulatory expectation and enforcement
  OCR guidance and webinars repeatedly emphasize that risk analysis is a core, required implementation specification under the Security Management Process standard (45 C.F.R. § 164.308(a)(1)(ii)(A)). OCR enforcement cases frequently cite incomplete, outdated, or missing risk analyses as a basis for settlements and corrective action plans.
• Cybersecurity and ransomware threats
  The Security Rule requires entities to evaluate risks and vulnerabilities in their environment and implement safeguards against "reasonably anticipated threats or hazards" [2]to ePHI. Modern ransomware campaigns, supply‑chain attacks, and insider misuse all fall squarely within that scope.
• Expanded digital and AI footprint
  HHS and ONC highlight that healthcare cyberthreats have grown to include cloud services, telehealth, mobile applications, and increasingly AI‑enabled tools that handle ePHI. A thorough SRA gives you a structured way to understand how each of these technologies affects the confidentiality, integrity, and availability of ePHI.
• Foundation for risk management
  The SRA feeds directly into risk management—implementing security measures to reduce risks to a reasonable and appropriate level—another required Security Rule activity.[3] You cannot prioritize or justify investments into your compliance program controls without first understanding your risk landscape.

In short, an SRA in 2026 is both a regulatory requirement and a practical roadmap for strengthening your security posture.

Overview: The Six Steps of a HIPAA Security Risk Assessment

HHS and ONC do not prescribe a single methodology but expect risk analysis to be accurate, thorough, and appropriately documented. A widely used structure—consistent with OCR guidance and reflected in HHS's Security Risk Assessment (SRA) Tool—includes six major steps:

1. Define scope and boundaries
2. Identify threats and vulnerabilities
3. Assess current security controls
4. Determine likelihood and impact of potential incidents
5. Evaluate and prioritize risks
6. Document findings and recommendations

We will walk through each step in detail, with practical checklists and specific considerations, including AI visibility in 2026.

Step 1: Define Scope and Boundaries

An SRA begins with clearly defining what is in scope. OCR guidance emphasizes that covered entities and business associates must consider all systems and processes that create, receive, maintain, or transmit ePHI.

Key tasks

• Identify all information systems that handle ePHI—for example:
• Electronic health record (EHR) systems
• Practice management and billing systems
• Patient portals and telehealth platforms
• Email systems used for ePHI
• Data warehouses and analytics platforms
• Backup and disaster recovery systems
• Mobile devices, laptops, and removable media
• Network infrastructure (servers, firewalls, switches) hosting or transporting ePHI
• Map where ePHI resides and flows—for example:
• Storage locations (on‑premises, cloud services, hosted applications)
• Interfaces between systems (e.g., EHR ↔ billing, EHR ↔ HIEs)
• Data flows to business associates and vendors handling ePHI
• Include physical and organizational boundaries—for example:
• Facilities where systems are located (data centers, clinics, remote sites)
• Networks and segments (e.g., clinical vs. guest networks)
• Business units and third parties with logical or physical access to ePHI

Scope checklist

At a minimum, your defined scope should list:

• All in‑scope systems and applications with ePHI
• All storage locations (servers, databases, file shares, cloud repositories, etc.)
• All transmission paths (internal networks, VPNs, external connections, etc.)
• Relevant business associates and vendors
• Physical locations where ePHI may be accessed or stored

The ONC/OCR SRA Tool and HCP's SRA Tool walk users through assets, vendors, and data tracking as part of the scoping and inventory process.

Step 2: Identify Threats and Vulnerabilities

Once scope is defined, you must identify potential threats (sources of harm) and vulnerabilities (weaknesses that could be exploited) relevant to your environment.

OCR guidance notes that risk analysis should consider "all reasonably anticipated threats"[4] to the confidentiality, integrity, and availability of ePHI. HHS and its partners provide several examples and tools that can help with this step, including:

Common threat categories

• Cyber threats
• Ransomware, malware, phishing, credential theft
• Exploitation of unpatched systems and insecure configurations
• Distributed denial‑of‑service (DDoS) attacks affecting availability
• Insider threats
• Unauthorized access or snooping by workforce members
• Misuse of legitimate privileges
• Accidental disclosure (misdirected emails, improper disposal)
• Physical threats
• Theft or loss of devices and media containing ePHI
• Natural disasters, fires, or floods affecting facilities
• Power failures or environmental hazards impacting systems
• Third‑party and supply‑chain threats
• Vendor security failures impacting hosted systems or services
• Business associates mishandling or exposing ePHI
• AI‑related threats
• AI tools generating inaccurate content stored in records
• AI systems trained on or exposed to ePHI without adequate safeguards
• Model or service compromise leading to confidentiality or integrity failures

Vulnerabilities to Consider

The SRA Tool and related HHS materials highlight typical vulnerability areas, such as:

• Lack of/weak encryption for data at rest or in transit
• Inadequate access controls (shared accounts, weak authentication, etc.)
• Poor patch and configuration management
• Insufficient logging and monitoring
• Incomplete backup and recovery capabilities
• Weak physical security (unlocked server rooms, untracked media, etc.)
• Gaps in policies, procedures, or workforce training

Threat and vulnerability checklist

For each in‑scope system or process, you should document:

• Reasonably anticipated threats that could affect confidentiality, integrity, or availability of ePHI
• Vulnerabilities or weaknesses that could allow those threats to cause harm
• Dependencies on vendors or AI‑enabled services that may introduce additional risk to your organization

This catalog forms the basis for later likelihood and impact analysis.

Step 3: Assess Current Security Controls

The Security Rule requires entities to evaluate their environments and implement reasonable and appropriate security measures. To do that, your risk analysis must include an assessment of existing controls—administrative, physical, and technical—and how effectively they address identified threats and vulnerabilities.

Control Categories to Review

HHS and NIST materials emphasize several core areas that map closely to HIPAA Security Rule implementation specifications and the SRA Tool's assessment domains:

• Administrative controls
• Security policies and procedures
• Workforce training and awareness
• Sanction policies and a disciplinary process
• Contingency planning, including backup and a Disaster Recovery Plan
• Physical controls
• Facility access controls (locks, badges, visitor management, etc.)
• Device and media controls (tracking, disposal, reuse, etc.)
• Environmental protections (HVAC, fire suppression, etc.)
• Technical controls
• Access controls (unique user IDs, authentication, role‑based access, etc.)
• Audit controls (system logs, access monitoring, alerting, etc.)
• Integrity controls (checks, validations, etc.)
• Transmission security (encryption, secure protocols, etc.)
• Endpoint and network protection (firewalls, anti‑malware, intrusion detection, etc.)
• Vendor and third‑party controls
• Business Associate Agreements (BAAs) that address security responsibilities
• Vendor risk assessments and ongoing oversight
• AI‑specific controls
• Policies governing AI use and data access
• Human review of AI outputs when used in clinical or operational contexts
• Technical safeguards around AI systems that process ePHI (access controls, logging, isolation, etc.)

Controls checklist

For each major system or process, you should document:

• Which controls are in place (by category)
• How they are implemented and enforced
• Any gaps relative to Security Rule requirements (e.g., missing or incomplete policies, insufficient logging, etc.)
• Whether controls extend to AI components and cloud‑based services affecting ePHI

The ONC/OCR SRA Tool and HCP's SRA Tool guides users through a series of questions and references to help assess controls in these areas and capture documentation along the way.

Step 4: Determine Likelihood and Impact of Potential Incidents

After identifying threats, vulnerabilities, and controls, you should estimate the likelihood that a particular threat-vulnerability combinations will lead to incidents, and the impact if they do. OCR guidance notes that an SRA should include evaluation of the potential impact on ePHI and the likelihood of occurrence.

Likelihood assessment

Likelihood can be expressed qualitatively (e.g., High/Medium/Low) or quantitatively, as long as your method is consistent and documented. Factors may include:

• Known exploitation of similar vulnerabilities in the sector
• Frequency of relevant threat activity (e.g., phishing attempts)
• Existing strength and coverage of controls
• Exposure (number of systems or users affected, external connectivity, etc.)

Impact assessment

Impact should consider potential harm to:

• Confidentiality - unauthorized disclosure of ePHI
• Integrity - unauthorized alteration or destruction of ePHI
• Availability - loss of or inability to access ePHI when needed

In healthcare, some impacts may include:

• Clinical harm or patient safety risks
• Inability to deliver care (e.g., during ransomware outages)
• Regulatory reporting and notification obligations
• Financial loss, reputational damage, and operational disruption

HHS's Risk Identification and Site Criticality (RISC) Toolkit—while focused on broader all‑hazards planning—illustrates how structured scoring of likelihood and consequences can support risk‑based prioritization of corrective actions.

Likelihood/impact checklist

For each risk scenario (threat + vulnerability + asset), record:

• Likelihood rating and rationale
• Impact rating for confidentiality, integrity, and availability
• Any assumptions or data sources used in your estimates

This allows you to compute or categorize overall risk levels in the next step.

Step 5: Evaluate and Prioritize Risks

Risk evaluation involves combining your likelihood and impact assessments to determine overall risk levels and rankings. OCR expects entities to use risk analysis results to inform risk management—deciding which risks to accept, mitigate, transfer, or avoid.

Example: Building a risk matrix

Many organizations use a simple matrix (e.g., 3×3 or 5×5) to translate qualitative likelihood and impact ratings into overall risk categories (e.g., High, Moderate, Low). For example:

• High likelihood + High impact = High risk
• Low likelihood + High impact = Moderate risk
• Medium likelihood + Low impact = Low or Moderate risk

The exact thresholds are up to you, but your methodology should be documented and applied consistently.

Prioritizing risks

Prioritization should account for:

• Overall risk level (e.g., High risks addressed before Moderate)
• Regulatory significance (risks directly tied to required Security Rule safeguards or OCR enforcement trends)
• Dependencies and compounding effects (e.g., a single control failure that affects multiple systems)
• Feasibility and cost of mitigation options

For AI‑related risks, consider both the potential scale of harm (e.g., systemic documentation errors or decision support failures, etc.) and the relative novelty of controls and oversight mechanisms in your environment.

Risk Evaluation Checklist

Your risk register should capture, at minimum:

• Risk description (system, threat, vulnerability, impact)
• Likelihood and impact ratings
• Overall risk level and priority ranking
• Initial thoughts on possible mitigations

This prioritized list becomes the input to risk management and remediation planning.

Step 6: Document Findings and Recommendations

OCR guidance stresses that an SRA must be documented and that the documentation should be sufficient to demonstrate that an accurate and thorough assessment has been conducted. The Security Rule does not specify a format, but your records should allow you—and regulators—to understand your process, assumptions, and decisions.

Core Documentation Elements

At a minimum, your SRA documentation should include the following:

• Methodology
• Risk analysis approach, including definitions of likelihood, impact, and risk levels
• Tools used (e.g., ONC/OCR SRA Tool, HCP SRA tool, etc.) and any frameworks referenced
• Scope and inventory
• Systems, applications, and data flows included in the analysis
• Facilities and organizational units in scope
• Threats, vulnerabilities, and controls
• Catalog of identified threats and vulnerabilities for each system or process
• Summary of current administrative, physical, and technical safeguards
• Risk ratings and Rationale
• Likelihood and impact assessments for key risk scenarios
• Overall risk levels and prioritization
• Findings and Recommendations
• Specific control gaps and weaknesses
• Recommended remediation actions, responsible parties, and timeframes
• Consideration of AI‑related risks and necessary governance measures

The ONC/OCR SRA Tool or HCP's SRA Tool can generate reports that summarize responses, identified risks, and suggested remediation steps, providing a structured starting point for your documentation.

Documentation checklist

Once you have completed your SRA, ensure that the final results:

• Are dated, and identify the period assessed
• Reflect current systems, technologies, and AI uses
• Include enough detail to support future updates and show progress over time
• Are retained according to your record retention policies and made available to appropriate leadership and oversight bodies

Integrating AI Visibility into Your 2026 Risk Analysis

While the HIPAA Security Rule does not mention AI explicitly, AI systems that create, receive, maintain, or transmit ePHI fall within its scope. Events, conferences, and other notable sources promoted by HHS OCR and NIST highlight AI‑enabled technologies as a growing area of focus in health information security.

To address AI visibility within your SRA:

• Include AI systems in your scope and inventory
• Identify any AI or machine‑learning tools that interact with ePHI (e.g., ambient documentation, clinical decision support, triage chatbots, analytics models, etc.).
• Document where these tools are hosted (on‑premises vs. cloud), how they are integrated with core systems, and who administers them.
• Assess AI‑specific threats and vulnerabilities
• Consider risks such as unauthorized access to training data, model inversion or extraction attacks, incorrect outputs being treated as authoritative, or AI services used outside approved workflows and scope.
• Evaluate whether AI vendors provide sufficient security assurances and whether your BAAs reflect HIPAA‑required safeguards.
• Evaluate controls and governance
• Review access controls, logging, and monitoring around AI tools, especially where ePHI is involved.
• Assess whether there is clear human oversight over AI‑generated content and decisions, and how errors or concerns can be reported and addressed.
• Incorporate AI into risk ratings and remediation plans
• Treat AI‑related risks like any other: document the likelihood, impact, and overall risk, then prioritize mitigation.
• Recommendations may include enhanced monitoring, stricter access controls, improved validation processes, or governance policies limiting certain AI uses until controls mature.

By explicitly including AI in your SRA, you demonstrate that your security program is accounting for current technology realities, not just legacy infrastructure.

Practical Checklists for a 2026 SRA

To summarize, here are concise checklists you can use to guide your 2026 Security Risk Analysis, aligned with OCR and ONC resources:

SRA preparation checklist

• Identify SRA leader and cross‑functional team (IT, security, compliance, privacy, clinical, etc.)
• Select methodology and tools (e.g., ONC/OCR SRA Tool, HCP's SRA Tool, etc.)
• Define timeframe and triggering events (e.g., annual review, major system changes, HIPAA Incidents, etc.)

Six‑step process checklist

1. Define scope and boundaries
• Inventory systems and applications with ePHI
• Map data flows and storage locations (including cloud and mobile)
• Identify facilities, networks, and business units in scope
• Include AI‑enabled systems that handle ePHI
2. Identify threats and vulnerabilities
• List cyber, insider, physical, and third‑party threats
• Identify vulnerabilities in technology, processes, and training
• Capture AI‑related threat scenarios (e.g., misuse of AI outputs)
3. Assess current security controls
• Review administrative, physical, and technical safeguards
• Evaluate vendor and business associate controls
• Assess controls specific to AI and cloud‑based systems
4. Determine likelihood and impact
• Rate likelihood for each key threat-vulnerability combination
• Rate impact on confidentiality, integrity, and availability of ePHI
• Document rationale for ratings
5. Evaluate and prioritize risks
• Apply a consistent risk matrix or scoring method
• Rank risks (High/Moderate/Low) with supporting reasoning
• Identify high‑priority risks for immediate remediation
6. Document findings and recommendations
• Summarize methodology, scope, and key assumptions
• Record threats, vulnerabilities, controls, and risk ratings
• List recommended remediation actions, owners, and timelines
• Generate and retain formal SRA report(s)

Follow‑through checklist

• Develop and approve a risk management plan based on SRA results
• Implement and track remediation activities
• Update SRA when significant changes occur (systems, AI deployments, incidents, etc.)
• Integrate SRA findings into training, policy updates, and governance discussions

REMEMBER—a Security Risk Analysis is not a one‑time exercise; it is a living process that must evolve with your technology, threat landscape, and with regulatory expectations. By following the six steps outlined above you align your organization with HIPAA Security Rule requirements and position yourself to manage both traditional cyber threats and emerging AI‑related risks in a structured, defensible way.