September 10, 2026

What Should a HIPAA Security Risk Analysis Include?

A HIPAA security risk analysis should do more than uncover technical weaknesses. Learn what healthcare leaders should evaluate from where ePHI exists and how it moves to threats, vulnerabilities, safeguards, risk prioritization, documentation, and practical next steps.
Image

Healthcare organizations know that protecting electronic protected health information (ePHI) is a core HIPAA Security Rule responsibility.

What is often less clear is what an effective HIPAA security risk analysis should evaluate, and whether an existing assessment is comprehensive enough to address the requirements.

Under the current HIPAA Security Rule, regulated entities must conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI.

The requirement applies to covered entities and business associates, and the Security Rule does not prescribe one specific risk-analysis methodology.

A HIPAA security risk analysis should:

  • Identify the ePHI an organization creates, receives, maintains, or transmits;
  • Determine where that information exists and how it moves;
  • Identify reasonably anticipated threats and vulnerabilities;
  • Evaluate existing safeguards;
  • Consider likelihood and potential impact;
  • Assign and prioritize risk levels; document the findings;
  • And use those findings to guide risk management.

The analysis should be revisited as the organization, technology, and risks change.

That makes the analysis broader than a vulnerability scan, cybersecurity checklist, or inventory of technical controls. For healthcare leadership, the objective is to develop a clear, documented understanding of where meaningful risks to ePHI exist, how significant those risks are, which safeguards are already in place, and what priorities should guide practical next steps.

This article addresses the current HIPAA Security Rule and is intended for general informational purposes. It is not legal advice and does not determine whether a particular organization is compliant with HIPAA.

Table of Contents Hide

What Does the HIPAA Security Rule Require from a Risk Analysis?

Risk analysis is a required implementation specification within the Security Management Process standard of the HIPAA Security Rule. Under 45 CFR § 164.308(a)(1)(ii)(A), regulated entities must conduct an accurate and thorough assessment of potential risks and vulnerabilities affecting the confidentiality, integrity, and availability of ePHI.

The HHS Guidance on Risk Analysis provides additional guidance on the scope and elements organizations should consider when performing that assessment.

The requirement applies to HIPAA covered entities including qualifying healthcare providers, health plans, and healthcare clearinghouses as well as their business associates. HHS refers to covered entities and business associates collectively as “regulated entities.”

HIPAA does not require every organization to use the same software, scoring system, worksheet, or consulting methodology. HHS recognizes that an appropriate approach can vary based on factors such as an organization's size, complexity, capabilities, technical infrastructure, and risk environment.

What matters is whether the analysis adequately addresses the objectives required by the Security Rule. This distinction is important when evaluating risk assessment tools.

The HHS Security Risk Assessment Tool, for example, can help small and medium-sized healthcare practices and business associates with their assessment activities, but use of the tool is neither required nor a guarantee of compliance.

Organizations that need help evaluating the technology side of these responsibilities may benefit from HIPAA IT compliance support focused on technical safeguards, identified gaps, documentation, and remediation priorities.

Current-rule note: HHS proposed significant modifications to the HIPAA Security Rule in December 2024 to strengthen cybersecurity requirements. As of September 9, 2026, those changes remain proposed. HHS expressly states that the current Security Rule remains in effect while rulemaking is underway. Proposed requirements should therefore not be presented as current HIPAA obligations.

A Complete Risk Analysis Starts with Understanding Where ePHI Exists

Before an organization can evaluate risk, it needs to understand the scope of the information being protected.

HHS guidance states that a HIPAA risk analysis should encompass potential risks and vulnerabilities affecting all ePHI the organization creates, receives, maintains, or transmits, regardless of the electronic medium, source, or location.

Organizations must also identify where ePHI is stored, received, maintained, or transmitted. In Healthcare & Behavioral Health IT environments, that scope can extend well beyond the electronic health record.

Area to Evaluate

Leadership Question

Examples

ePHI

What electronic protected health information do we handle?

Patient records, clinical documentation, billing information, electronic communications containing ePHI

Systems and applications

Where is ePHI created, processed, stored, or accessed?

EHRs, practice-management systems, cloud applications, servers, workstations

Devices

Which devices can store or access ePHI?

Laptops, desktops, tablets, mobile devices, removable media where applicable

Data movement

How does ePHI move between people and systems?

Internal networks, cloud services, remote access, electronic exchanges, backups

Locations

Where can ePHI be accessed or maintained?

Clinics, administrative offices, remote-work environments, multiple facilities

Third parties

Which outside organizations create, receive, maintain, or transmit ePHI?

Business associates, technology providers, cloud vendors, consultants

An asset inventory can help establish this picture, but an inventory alone is not the risk analysis. Leadership also needs visibility into data flows: where ePHI originates, where it travels, who can access it, where copies may exist, and which external organizations participate in those workflows.

This is particularly important as healthcare environments become more distributed. A clinical application may be cloud-hosted, employees may access information remotely, backups may reside with another provider, and third parties may process or maintain ePHI outside the organization's physical facility.

The central question is not simply, “What technology do we own?”

It is:

“Where does our ePHI exist, how does it move, and what systems, people, locations, and outside parties affect its security?”

Identify Threats, Vulnerabilities, and the Safeguards Already in Place

Once the scope of ePHI is understood, the organization can evaluate what could put that information at risk.

HHS risk-analysis guidance separates several related concepts:

  • A threat is something capable of accidentally triggering or intentionally exploiting a weakness.
  • A vulnerability is a technical or nontechnical weakness that could be triggered or exploited.
  • Risk reflects the relationship between a threat, the vulnerability it could exploit, the likelihood of that occurring, and the resulting impact.

A practical analysis should also consider the security safeguards already in place.

Component

What It Means

Example

Threat

Something that could cause harm

Cyberattack, employee mistake, power failure

Vulnerability

A weakness the threat could exploit or trigger

Weak access controls, poor configuration, ineffective procedure

Safeguard

A measure that helps reduce the risk

MFA, access restrictions, documented procedures, backup controls

Risk

The potential consequence created by the overall scenario

Unauthorized ePHI access, data loss, unavailable systems

Threats are not limited to cybercriminal activity. HHS guidance identifies human, natural, and environmental threats and recognizes both intentional and unintentional human actions.

Vulnerabilities can likewise be technical or nontechnical; ineffective policies and procedures can create weaknesses just as configuration problems can.

The organization should then evaluate its existing administrative, physical, and technical safeguards and determine whether those measures are present, appropriate, properly configured, and being used as intended.

Depending on the environment, relevant safeguards and cybersecurity services may involve:

  • Identity and access controls
  • Endpoint protection
  • Security monitoring
  • Network security
  • Backup and recovery
  • Incident response
  • And other protections appropriate to the risks identified

The purpose is not to create a generic list of cybersecurity products. It is to determine how the organization's actual safeguards affect identified risks to ePHI.

For example, security monitoring may be relevant when evaluating an organization's ability to detect certain threats.

Backup and recovery controls may become particularly relevant when evaluating risks to the availability and integrity of ePHI.

Why a Vulnerability Scan Is Not a HIPAA Security Risk Analysis

A vulnerability scan can provide valuable information about technical weaknesses, but it is not equivalent to a HIPAA security risk analysis.

HHS requires a much broader analysis encompassing all ePHI, reasonably anticipated threats, technical and nontechnical vulnerabilities, existing safeguards, likelihood, impact, risk levels, and documentation.

A technical scan addresses only part of that picture.

HIPAA Security Risk Analysis

Vulnerability Scan

Evaluates risks affecting all ePHI in scope

Primarily evaluates technical systems

Considers threats and vulnerabilities

Primarily identifies technical weaknesses

Includes technical and nontechnical vulnerabilities

Primarily technical

Considers existing safeguards

May identify or validate some technical controls

Evaluates likelihood and potential impact

Usually focuses on technical severity and exposure

Determines organizational risk levels

Typically ranks technical findings

Supports broader risk-management decisions

Supports technical remediation

A vulnerability scan may therefore serve as evidence or an input to the analysis. It can identify outdated software, configuration weaknesses, exposed services, or other technical conditions that deserve further evaluation.

But leadership should be cautious if a product or provider describes a vulnerability scan or any other single technical test as if it independently satisfies the broader HIPAA risk-analysis requirement.

A more useful question is:

Does the assessment examine the organization's complete ePHI environment and convert identified threats, vulnerabilities, and safeguards into documented risk decisions?

A broader healthcare IT security review can also help identify areas warranting attention, but it should not be confused with the organization's formal HIPAA Security Rule risk analysis.

Evaluate Likelihood, Impact, and the Level of Risk

Finding a weakness is not the same as understanding its risk.

HHS guidance calls for organizations to consider the probability of potential risks and assess the magnitude of the potential impact if a threat triggers or exploits a vulnerability.

Organizations can use qualitative methods, quantitative methods, or a combination of the two when evaluating impact. They should then assign risk levels to the threat-and-vulnerability combinations identified through the analysis.

A practical decision framework is:

Threat + Vulnerability + Existing Safeguards → Likelihood + Impact → Risk Level → Priority

Consider an illustrative scenario. A healthcare organization allows remote access to a system containing ePHI. Credential theft is a relevant threat. Weak authentication could be a vulnerability. Existing access controls, monitoring, and authentication safeguards affect the likelihood and potential consequences.

The organization would evaluate those factors together rather than simply recording “credential theft” on a checklist.

Potential impact should also be considered through the lens of the Security Rule's three core protection objectives:

  • Confidentiality: Could unauthorized people gain access to ePHI?
  • Integrity: Could ePHI be improperly changed, corrupted, or destroyed?
  • Availability: Could authorized users lose access to information or systems when needed?

The resulting risk level gives leadership a method for prioritizing remediation rather than treating every finding as equally urgent.

This is where the risk analysis starts becoming a management tool. A prioritized view of risk can help leadership make more informed decisions about budgets, projects, accountability, security investments, and operational priorities.

That prioritized understanding of risk can also strengthen broader IT compliance and audit readiness by giving leadership clearer visibility into identified gaps, remediation priorities, and supporting documentation.

Document the Analysis and Keep Risk Analysis Separate from Risk Management

A HIPAA security risk analysis must be documented, although HHS does not mandate one specific documentation format. HHS also describes that documentation as a direct input into the organization's risk management process.

A useful risk-analysis record should allow the organization to understand what was evaluated and how conclusions were reached.

Depending on the methodology, that documentation may include the scope of ePHI reviewed, identified threats and vulnerabilities, current safeguards, likelihood assessments, potential impacts, assigned risk levels, and resulting corrective-action considerations.

The key distinction is:

Risk Analysis

Risk Management

Identifies and evaluates risk

Determines what to do about identified risk

Establishes scope and findings

Implements appropriate security measures

Evaluates likelihood and impact

Reduces risk to a reasonable and appropriate level

Produces documented risk priorities

Produces remediation and ongoing management actions

HHS explains risk management as the implementation of security measures sufficient to reduce risks to ePHI and meet the Security Rule's general security standards.

That distinction matters operationally. Completing the assessment does not resolve the risks it identifies.

Leadership needs a mechanism for determining which findings require action, assigning responsibility, establishing priorities and timelines, documenting decisions, and tracking remediation.

The Security Rule also has documentation-retention requirements. Documentation of required actions, activities, and assessments generally must be retained for six years from its creation or from the date it was last in effect, whichever is later.

Documentation must also be reviewed and updated as needed in response to environmental or organizational changes affecting ePHI security.

When Should a HIPAA Security Risk Analysis Be Reassessed?

HIPAA does not establish one universal rule requiring every regulated entity to perform its risk analysis exactly once each year.

HHS describes risk analysis as an ongoing process and states that the current Security Rule does not specify a single frequency for performing it as part of a comprehensive risk-management process. Frequency depends on the circumstances of the organization's environment.

This is an important distinction. An annual review may be an appropriate governance practice for some organizations, but leadership should not assume that scheduling an assessment once every 12 months, by itself, satisfies the organization's ongoing responsibility to respond to meaningful change.

This is also why HIPAA IT compliance checklists should not be treated as a substitute for an ongoing risk-analysis and risk-management process.

HHS specifically identifies circumstances such as a security incident, a change in ownership, turnover in key staff or management, or plans to introduce new technology as situations in which potential risk should be analyzed. More broadly, environmental or operational changes affecting ePHI security should drive review and updates.

For a healthcare organization, practical reassessment triggers can therefore include significant changes to technology, locations, vendors, ePHI workflows, remote access, infrastructure, or other parts of the environment that materially affect risk.

The governance objective is not simply to prove that an assessment has a recent date on it. Leadership should be able to determine whether the analysis still accurately reflects how the organization operates today and the risks that exist today.

What About the Proposed HIPAA Security Rule Changes?

As of September 9, 2026, HHS's cybersecurity modifications to the HIPAA Security Rule remain a proposed rule, not the Security Rule currently in effect. HHS explicitly distinguishes the current rule from the proposed modifications and states that the current Security Rule remains in effect while rulemaking continues.

Healthcare leaders should monitor regulatory developments and plan for change where appropriate, but proposed provisions should not be represented as present-day HIPAA requirements until they are finalized and become applicable.

From Risk Findings to Practical IT Priorities

A useful HIPAA security risk analysis should ultimately give leadership a clearer basis for action.

Once risks have been identified and prioritized, the organization should be able to determine which findings require attention, which safeguards may need improvement, who is responsible for each next step, what resources are required, and how remediation decisions will be documented and monitored.

Leadership should be able to answer questions such as:

  • Which risks require the highest priority?
  • Are current safeguards reasonable and appropriate for the identified risks?
  • Which weaknesses require technical, operational, or administrative action?
  • Who is responsible for each next step?
  • Which corrective actions require budget or project planning?
  • What documentation or evidence should be maintained?
  • When should specific risks or broader analysis be reassessed?
  • Are responsibilities between internal leadership, IT resources, vendors, and other advisers clearly defined?

The analysis itself does not make these decisions automatically. Its value comes from giving leadership a credible, documented foundation for risk management.

For healthcare organizations that need additional support on the IT side of that process, thirtyone3 technology can help clarify the technical environment in scope, evaluate defined safeguards and identified gaps, organize supporting technical evidence, and develop practical remediation priorities.

The organization remains responsible for its overall HIPAA compliance program, including governance, workforce practices, policies, physical safeguards, vendors, legal interpretation, and organizational decisions.

Where specialized legal or compliance guidance is required, that work should remain with the appropriate qualified adviser.

Leadership Takeaway

A HIPAA security risk analysis should do more than identify technical weaknesses. It should give the organization a documented understanding of its ePHI environment, the threats and vulnerabilities that matter, the safeguards already in place, the likelihood and impact of identified risks, and the priorities that should guide risk management.

The strongest outcome is not simply a completed assessment. It is a clearer understanding of risk that leadership can use to assign responsibility, prioritize remediation, document decisions, and reassess the environment as technology and operations change.

Need a Clearer View of Your HIPAA IT Readiness?

If questions remain about your technology environment, technical safeguards, risk-analysis findings, documentation, or remediation priorities, start with a practical conversation.

thirtyone3 technology will discuss what is happening in your environment, the concerns that matter most to leadership, and whether our IT compliance and healthcare experience aligns with what you need.

If there is a potential fit, we can recommend the appropriate discovery or assessment step and explain what it includes.

Schedule a 30-Minute IT Fit Call

More Questions About HIPAA Security Risk Analysis

No. The current HIPAA Security Rule does not prescribe one specific risk-analysis methodology. HHS recognizes that appropriate methods can vary based on an organization's size, complexity, capabilities, and environment. The HHS Security Risk Assessment Tool can assist small and medium-sized healthcare practices and business associates, but its use is not required and does not guarantee compliance.