Category: Administrative Safeguards

Security Risk Analysis

Also known as: SRA, Security Risk Assessment, HIPAA Risk Analysis, Risk Analysis

Simply put

A Security Risk Analysis is a structured review a healthcare organization performs to understand where the electronic health information it holds could be exposed, lost, or misused. It looks at the threats and weaknesses affecting the systems that store or transmit this data and helps the organization decide how serious each risk is. It is generally an ongoing activity rather than a one-time task, and it forms a foundation for deciding what safeguards to put in place.

Formal definition

Under the HIPAA Security Rule, a Security Risk Analysis is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) held by a covered entity or business associate. It is a required administrative safeguard implementation specification and involves a systematic, disciplined examination of risk, typically including identifying where ePHI is created, received, maintained, or transmitted; identifying and documenting reasonably anticipated threats and vulnerabilities; assessing current security measures; and determining the likelihood and potential impact of threat occurrence to establish the magnitude of risk. HHS OCR guidance characterizes risk analysis as an ongoing process that should be reviewed and updated as needed rather than a single event. Its scope under the Security Rule is limited to ePHI; risks to PHI in oral or paper form fall under the Privacy Rule and are outside this analysis. Tools such as the ONC/HHS Security Risk Assessment Tool may assist smaller providers, but use of any tool does not by itself guarantee compliance, and state law, the HITECH Act, or frameworks such as the HITRUST CSF may impose additional or more specific requirements. Readers should confirm current requirements against the applicable regulatory text.

Why it matters

The Security Risk Analysis sits at the foundation of an organization's compliance with the HIPAA Security Rule. It is a required implementation specification within the administrative safeguards, and nearly every other security decision an organization makes, which safeguards to prioritize, how to address addressable implementation specifications, where to invest limited resources, depends on the understanding produced by this analysis. Without an accurate and thorough risk analysis, a covered entity or business associate generally lacks the basis to demonstrate that its security measures are reasonable and appropriate for the ePHI it holds.

HHS OCR guidance characterizes risk analysis as an ongoing process rather than a one-time event, and this distinction matters in practice. Systems change, new threats emerge, and the places where ePHI is created, received, maintained, or transmitted shift over time. An analysis that is stale or narrow in scope may leave significant exposures undocumented, which can undermine an organization's compliance posture. In enforcement contexts, the absence or inadequacy of a risk analysis has frequently been a recurring concern raised by HHS OCR, though organizations should confirm current enforcement priorities and any associated figures against current OCR guidance.

It is important to keep the scope of this analysis in perspective. Under the Security Rule, the risk analysis is limited to ePHI; risks to PHI in oral or paper form fall under the Privacy Rule and are outside its scope. Performing a risk analysis, or using a tool to support one, does not by itself guarantee compliance, and state law, the HITECH Act, or frameworks such as the HITRUST CSF may impose additional or more specific requirements beyond the baseline HIPAA obligation.

Who it's relevant to

Covered Entities

Healthcare providers, health plans, and healthcare clearinghouses that create, receive, maintain, or transmit ePHI are directly obligated under the Security Rule to conduct a risk analysis. For these organizations, the analysis is the starting point for determining which administrative, physical, and technical safeguards are reasonable and appropriate for their environment.

Business Associates and Subcontractors

Business associates, and their subcontractors that handle ePHI, are independently subject to the Security Rule and are generally expected to perform their own risk analysis for the ePHI within their control. Their specific obligations are also shaped by business associate agreements, and they should not assume a covered entity's analysis covers their systems.

Security and Compliance Officers

Security officers, privacy officers, and compliance staff are typically responsible for scoping, conducting, documenting, and updating the risk analysis, and for translating its findings into risk management decisions. They should treat it as an ongoing activity and maintain documentation that reflects the current state of the organization's ePHI environment.

Small to Medium Providers

Smaller provider organizations with limited resources may find guided tools such as the ONC/HHS Security Risk Assessment Tool helpful in working through the process. They should keep in mind that using such a tool supports but does not by itself guarantee compliance, and that additional requirements may apply.

Organizations Pursuing HITRUST Certification

Organizations working within the HITRUST CSF should recognize that HITRUST certification is not a legal requirement and does not by itself establish HIPAA compliance. The HITRUST CSF may impose additional or more specific requirements, and its risk-related controls should be reconciled against the underlying HIPAA Security Rule obligation to perform a risk analysis.

Inside SRA

Scope Identification

A determination of where ePHI is created, received, maintained, or transmitted across the organization, including systems, applications, devices, media, and network locations. The Security Rule's risk analysis obligation applies specifically to electronic protected health information.

Asset and Data Flow Inventory

An inventory of information systems and assets that handle ePHI, along with an understanding of how ePHI moves into, through, and out of those systems. This supports identifying where safeguards are needed.

Threat and Vulnerability Identification

Documentation of reasonably anticipated threats (such as human, environmental, or technical) and vulnerabilities that could be exploited, forming the basis for evaluating exposure to ePHI.

Assessment of Current Security Measures

An evaluation of the administrative, physical, and technical safeguards already in place, and how effectively they address identified threats and vulnerabilities.

Likelihood and Impact Determination

An analysis of the probability that a given threat exploits a vulnerability and the potential impact on the confidentiality, integrity, and availability of ePHI, used to characterize the level of risk.

Risk Level Determination and Documentation

An assigned risk rating for identified risks and written documentation of the analysis. The risk analysis is generally treated as a required implementation specification under the Security Rule's administrative safeguards, and documentation supports demonstrating that the analysis was performed.

Relationship to Risk Management

The risk analysis feeds a broader risk management process in which the covered entity or business associate implements measures sufficient to reduce risks to a reasonable and appropriate level. Risk analysis is a distinct step that informs, but does not replace, ongoing risk management.

Common questions

Answers to the questions practitioners most commonly ask about SRA.

Is a security risk analysis a one-time project we can complete and then set aside?

No. A security risk analysis is generally understood to be an ongoing process rather than a one-time task. The Security Rule contemplates that covered entities and business associates conduct an accurate and thorough assessment of risks and vulnerabilities to ePHI, and most guidance treats this as something that should be reviewed and updated periodically and when significant changes occur in the environment, operations, or technology. Treating it as a single completed project can leave newly introduced risks unassessed.

Does adopting a security framework or achieving a certification like HITRUST CSF satisfy the risk analysis requirement automatically?

Not by itself. Using a control framework or pursuing HITRUST CSF certification can support and inform your risk analysis efforts, but HITRUST is a private organization and its certification is not a legal requirement, nor does it by itself establish HIPAA compliance. The Security Rule requires an organization-specific risk analysis addressing your own ePHI, systems, and vulnerabilities. Readers should treat frameworks as tools that assist the process, not as substitutes for the analysis itself, and verify current expectations against the applicable regulatory text and current HITRUST CSF version.

What is the general scope of what a security risk analysis should cover?

A security risk analysis under the Security Rule generally focuses on electronic protected health information (ePHI) and should typically identify where ePHI is created, received, maintained, or transmitted across your systems and workflows. It commonly examines threats and vulnerabilities affecting that ePHI and evaluates the likelihood and potential impact of those risks. Note that the Security Rule addresses only ePHI; PHI in oral or paper form falls under the broader Privacy Rule and is generally addressed through separate assessments.

How does the risk analysis relate to the administrative, physical, and technical safeguards?

The risk analysis generally informs how an organization applies the Security Rule's administrative, physical, and technical safeguards. It helps determine which measures are appropriate given the identified risks, and it is particularly relevant to addressable implementation specifications, where an organization assesses whether a specification is reasonable and appropriate for its environment. Keep in mind that addressable does not mean optional; it generally requires implementing the specification, adopting an equivalent alternative, or documenting why it is not reasonable and appropriate.

How should the results of a risk analysis be documented and used?

In most cases, the findings of a risk analysis feed into a risk management process, where identified risks are prioritized and addressed through appropriate safeguards. Documentation of the analysis, the decisions made, and the rationale behind them is generally expected and can be important to demonstrate the process during an inquiry or review. Because no measure guarantees compliance or prevents all breaches, thorough documentation of a reasoned process is typically emphasized over any single outcome.

Do business associates need to conduct their own risk analysis, or does the covered entity's analysis cover them?

Business associates are generally expected to conduct their own security risk analysis with respect to the ePHI they create, receive, maintain, or transmit. Obligations flow through defined relationships, and a covered entity's risk analysis does not typically extend to cover a business associate's own systems and environment. Business associate agreements set out responsibilities between the parties, but each organization is generally responsible for assessing risks to the ePHI within its own control. Subcontractors handling ePHI may have similar responsibilities under their own agreements.

Common misconceptions

A security risk analysis is a one-time project that can be completed and set aside.

A risk analysis is generally expected to be an ongoing process rather than a single event. It should typically be reviewed and updated in response to changes in the environment, such as new systems, operations, or threats. Readers should confirm expectations against current OCR guidance.

Achieving HITRUST CSF certification or passing a security assessment satisfies the Security Rule's risk analysis requirement and establishes HIPAA compliance.

HITRUST is a private organization and the HITRUST CSF is a certifiable control framework, not a legal requirement. Certification does not by itself establish HIPAA compliance or substitute for the risk analysis required under the Security Rule. The risk analysis is a HIPAA obligation enforced by HHS OCR.

A generic checklist or vendor questionnaire is the same as a security risk analysis.

The risk analysis requires an organization-specific assessment of where ePHI exists and the threats, vulnerabilities, likelihood, and impact affecting it. A generic checklist does not, by itself, meet the analysis expectation, which is tied to the entity's actual environment and data flows.

Best practices

Define and document the full scope by identifying all systems, devices, media, and locations where ePHI is created, received, maintained, or transmitted before beginning the analysis.

Assess current administrative, physical, and technical safeguards against identified threats and vulnerabilities, keeping in mind that addressable implementation specifications are not optional and must be addressed appropriately.

Document likelihood, impact, and resulting risk levels in writing so the organization can demonstrate that the analysis was performed and support subsequent risk management decisions.

Treat the risk analysis as an ongoing process, reviewing and updating it when systems, operations, technologies, or threats change rather than relying on a single point-in-time assessment.

Connect risk analysis findings to a documented risk management plan that implements measures to reduce identified risks to a reasonable and appropriate level.

Verify specific requirements, expectations, and any applicable citations against the current Security Rule text and current OCR guidance, and consider that the HITECH Act or state law may impose additional obligations beyond HIPAA.