Skip to main content
Category: Administrative Safeguards

Risk Management

Also known as: Security Risk Management, Risk Mitigation Process
Simply put

Risk management is the ongoing process of identifying threats to an organization's information and assets, assessing how serious those threats are, and taking steps to reduce them to an acceptable level. In the HIPAA context, it generally refers to how a covered entity or business associate keeps electronic protected health information (ePHI) reasonably protected. It is a continuous activity rather than a one-time task, and no risk management program can guarantee that all breaches are prevented.

Formal definition

Risk management is the systematic process of identifying, assessing, prioritizing, and addressing risks to organizational operations, assets, and information. Under the HIPAA Security Rule, risk management is generally treated as a required administrative safeguard within the security management process: following a risk analysis, an organization must implement security measures sufficient to reduce risks and vulnerabilities to ePHI to a reasonable and appropriate level. It is distinct from the underlying risk analysis (which identifies and evaluates risks) in that it focuses on the ongoing selection, implementation, monitoring, and control of mitigating measures. Note that the HIPAA Security Rule applies only to ePHI, not to PHI in oral or paper form, and that the HITECH Act, state law, or frameworks such as the HITRUST CSF may impose additional or more specific requirements. Practitioners should confirm current regulatory obligations against the applicable CFR text and current HHS OCR guidance.

Why it matters

Risk management sits at the core of the HIPAA Security Rule's security management process. Because the Security Rule generally treats risk management as a required administrative safeguard, an organization that cannot demonstrate an ongoing process for reducing risks to ePHI may struggle to show it has met its obligations. Risk analysis identifies and evaluates the threats and vulnerabilities, but risk management is where an organization actually selects, implements, monitors, and adjusts the measures that bring those risks down to a reasonable and appropriate level.

The distinction matters in practice: identifying a risk is not the same as addressing it, and regulators and auditors generally look for evidence that identified risks were acted upon over time. Risk management is a continuous activity rather than a one-time exercise, since threats, systems, and business relationships change. It applies to covered entities and business associates alike wherever they create, receive, maintain, or transmit ePHI.

It is important to be realistic about what risk management can accomplish. No risk management program can guarantee that all breaches are prevented; the goal is to reduce risks and vulnerabilities to a reasonable and appropriate level, not to eliminate them entirely. Organizations should also remember that the HIPAA Security Rule covers only ePHI, and that the HITECH Act, state law, or frameworks such as the HITRUST CSF may impose additional or more specific requirements that go beyond the baseline HIPAA obligations.

Who it's relevant to

Security Officers
Security officers are typically responsible for operating the security management process, including translating the results of a risk analysis into concrete mitigating measures and monitoring their effectiveness over time. They must be able to document that identified risks to ePHI are being addressed on an ongoing basis, not just cataloged once.
Covered Entities and Business Associates
Both covered entities and business associates that create, receive, maintain, or transmit ePHI are generally expected to implement risk management as part of their Security Rule compliance. Business associate obligations attach through defined relationships and agreements, so vendors handling ePHI should understand where these duties apply to them.
Compliance and Privacy Officers
Compliance and privacy officers help ensure that risk management activities align with broader regulatory obligations, keeping in mind that the Security Rule addresses ePHI while other rules and state laws may reach PHI in oral or paper form. They should confirm current requirements against applicable regulation and HHS OCR guidance.
Auditors and Assessors
Auditors and assessors reviewing a HIPAA program generally look for evidence that risk management is continuous and that identified risks have been acted upon, including how addressable implementation specifications were evaluated and documented. Those working with the HITRUST CSF should note it may impose additional or more specific control requirements beyond HIPAA, and that HITRUST certification does not by itself establish HIPAA compliance.

Inside Risk Management

Risk Management (Security Rule context)
Under the HIPAA Security Rule, risk management is a required administrative safeguard implementation specification that obligates covered entities and business associates to implement security measures sufficient to reduce risks and vulnerabilities to ePHI to a reasonable and appropriate level. It applies specifically to electronic protected health information, not to PHI in oral or paper form.
Relationship to Risk Analysis
Risk management typically follows and depends on the risk analysis process. The risk analysis identifies and assesses potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI; risk management then addresses those identified risks through selected security measures. The two are distinct but interdependent required implementation specifications.
Reasonable and Appropriate Standard
The Security Rule generally does not mandate specific technologies. Instead, measures are expected to be reasonable and appropriate given factors such as the organization's size, complexity, capabilities, technical infrastructure, and the costs and probability and criticality of potential risks. Readers should verify the specific flexibility language against the current regulatory text.
Ongoing, Iterative Process
Risk management is generally treated as a continuous activity rather than a one-time project. As systems, threats, and organizational circumstances change, risk management measures are typically expected to be reviewed and updated to remain reasonable and appropriate.
Scope Across Relationships
Risk management obligations apply to covered entities and, through the HITECH Act and business associate agreements, to business associates and their subcontractors handling ePHI. Obligations attach through these defined relationships rather than directly to every vendor that may touch data.
Distinction from HITRUST Risk Management
The HITRUST CSF, a certifiable control framework maintained by the private HITRUST organization, includes risk management controls that may map to HIPAA requirements. However, adopting HITRUST controls or achieving HITRUST certification is not a legal requirement and does not by itself establish HIPAA compliance.

Common questions

Answers to the questions practitioners most commonly ask about Risk Management.

Is completing a risk analysis the same as risk management under the HIPAA Security Rule?
No. Although the two are closely related and often discussed together, they are distinct implementation specifications under the Security Rule's administrative safeguards. Risk analysis is generally the process of identifying and assessing risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI, while risk management is the process of implementing security measures sufficient to reduce those identified risks and vulnerabilities to a reasonable and appropriate level. Both are required implementation specifications, and completing an assessment without acting on its findings would typically leave the risk management obligation unmet. Readers should confirm the specific requirements against the current regulatory text.
Does achieving HITRUST certification satisfy the HIPAA risk management requirement?
Not by itself. HITRUST is a private organization and the HITRUST CSF is a certifiable control framework, whereas HIPAA is a US federal regulatory framework enforced by HHS OCR. Working through the HITRUST CSF may help an organization structure and document its risk management activities, but HITRUST certification is not a legal requirement and does not by itself establish HIPAA compliance. An organization remains responsible for meeting the Security Rule's risk management obligation as interpreted by HHS OCR, and should verify how any framework-based work maps to current regulatory expectations.
How often should risk management activities be revisited?
The Security Rule generally frames risk analysis and risk management as ongoing rather than one-time efforts. In most cases organizations revisit these activities periodically and in response to significant changes, such as new systems, new services, operational changes, or newly identified threats or vulnerabilities. The regulation does not prescribe a single universal frequency in the way some readers expect, so the appropriate cadence depends on the organization's environment. Readers should confirm current guidance and consider that state law or other frameworks may impose additional expectations.
How should addressable implementation specifications be handled within risk management?
Addressable does not mean optional. For an addressable specification, an organization generally must assess whether the specification is reasonable and appropriate for its environment, and then either implement it, implement an equivalent alternative measure, or document why it is not reasonable and appropriate and how the risk is otherwise addressed. This analysis and its rationale should typically be documented as part of the risk management process. The distinction between required and addressable specifications applies within the Security Rule's administrative, physical, and technical safeguards, and readers should confirm the classification of specific specifications against the current regulatory text.
What should be documented as part of a risk management program?
Documentation typically includes the identified risks and vulnerabilities, the security measures selected to reduce them, the rationale for decisions (including decisions about addressable specifications and any alternative measures), and evidence that measures were implemented and reviewed over time. Because risk management is generally treated as an ongoing process, maintaining records that show how decisions were reached and revisited can be important when demonstrating reasonable and appropriate efforts. Organizations should verify recordkeeping expectations against current HHS OCR guidance.
How do risk management obligations apply to business associates and their subcontractors?
The Security Rule's risk management obligations generally apply to covered entities and to business associates that create, receive, maintain, or transmit ePHI. Obligations extend to subcontractors through the chain of business associate agreements rather than through direct regulation of every vendor that touches data. In practice this means a covered entity or business associate typically addresses its own risk management program while relying on defined contractual relationships to flow appropriate obligations downstream. Readers should confirm how these obligations are allocated in their specific agreements and against the current regulatory text.

Common misconceptions

Risk management and risk analysis are the same thing.
They are distinct implementation specifications under the Security Rule. Risk analysis identifies and assesses risks to ePHI, while risk management implements measures to reduce those identified risks to a reasonable and appropriate level. One generally informs the other, but performing one does not satisfy the requirement for the other.
Completing a risk management effort once satisfies the HIPAA requirement indefinitely.
Risk management is generally an ongoing, iterative process. As systems, threats, and organizational circumstances change, measures are typically expected to be reviewed and updated. A single point-in-time effort does not, in most cases, remain adequate over time.
Implementing strong risk management measures or achieving HITRUST certification guarantees HIPAA compliance and prevents breaches.
No measure guarantees compliance or prevents all breaches. Risk management aims to reduce risks to a reasonable and appropriate level, not to eliminate them. HITRUST certification is a private framework outcome and does not by itself establish HIPAA compliance, which is enforced by HHS OCR.

Best practices

Base risk management decisions on a documented, current risk analysis so that selected measures address specific identified risks and vulnerabilities to ePHI.
Select security measures that are reasonable and appropriate for your organization's size, complexity, capabilities, and technical infrastructure, and document the rationale for the measures chosen.
Treat risk management as an ongoing cycle by scheduling periodic reviews and updating measures when systems, threats, or organizational circumstances change.
Extend risk management expectations to business associates and subcontractors through appropriately scoped business associate agreements, recognizing that obligations attach through these defined relationships.
Maintain thorough documentation of risk management activities, decisions, and their justifications to support demonstrations of reasonable and appropriate diligence.
If you use the HITRUST CSF to structure controls, verify how those controls map to HIPAA requirements and confirm details against the current HITRUST CSF version and current regulatory guidance, remembering that certification does not by itself establish HIPAA compliance.