What goes in a HIPAA risk management plan

Every OCR settlement that cites a risk analysis failure also cites the risk management plan. They are two separate requirements in the Security Rule, and both have to be documented.

45 CFR § 164.308(a)(1)(ii)(A) covers the risk analysis — the assessment of what could go wrong. 45 CFR § 164.308(a)(1)(ii)(B) covers the risk management plan — the documented response to what you found.

Most articles about HIPAA compliance focus on the risk analysis and stop there. This one covers the second document.

What the rule requires

The Security Rule requires covered entities to "implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level."

That is the standard: risks reduced to a "reasonable and appropriate" level. Not zero. Not eliminated. Reduced and managed. And documented.

The risk management plan is the documentation of how you plan to reduce each risk your analysis identified. It needs to exist, it needs to be current, and it needs to be tied to specific risks.

How the risk management plan relates to the risk analysis

Think of the two documents as paired. The risk analysis answers: "What are our risks?" The risk management plan answers: "What are we doing about them?"

You cannot have a defensible risk management plan without a current risk analysis. And a risk analysis with no corresponding plan leaves the second half of the requirement unsatisfied.

OCR's investigative data request letters ask for both simultaneously: "copies of the most recent risk analysis" and "policies and procedures for managing identified risks." Investigators expect to see the connection between them.

What a risk management plan needs to contain

The rule does not prescribe a format. Based on the HHS 2010 guidance, OCR settlement patterns, and NIST SP 800-30, a defensible plan should contain:

1. A reference to the risk analysis it addresses. Date the analysis was completed, who conducted it. This ties the plan to a specific, current assessment.

2. A list of identified risks, by priority. Not all risks are equal. Your plan should distinguish between immediate, high-likelihood gaps (weak passwords on your EHR, no MFA on remote access) and lower-priority long-term items (network segmentation upgrades, formal pen testing).

3. A specific action for each risk. Not "we will address this" but "we will enable MFA on the EHR portal by [date]" or "we will execute BAAs with all vendor relationships by [date]." Vague language in a risk management plan is a flag for investigators.

4. A responsible party for each action. Who is accountable? For a small practice, this is often the practice owner or office manager. It can be a vendor for technical controls they manage. The name (or role) should be there.

5. A timeline. When will each action be completed? A risk management plan with no dates is not a management plan — it is a list of intentions.

6. A date for review. The plan should be a living document reviewed at least annually alongside the risk analysis. Note when the next review is scheduled.

The three-tier structure that works for small practices

Risk management plans are easier to act on when risks are sorted by urgency. The tier structure that maps to actual HIPAA enforcement priorities:

This week. Things you can do with no budget and limited technical skill: enable MFA on your email account and EHR portal, update the Notice of Privacy Practices, revoke access for any departed staff, verify that every workforce member with ePHI access has a current sanctions agreement on file.

Vendor conversations. Things that require a call or email to a service provider: executing or updating BAAs with your EHR vendor, billing company, cloud backup service, and telehealth platform; confirming that encryption is enabled by default; asking your IT provider about patch management.

Budget decisions. Things that require capital and planning: network segmentation, replacing outdated devices, formal workforce training programs, penetration testing.

This structure is not the Security Rule's language — it is a practical organizing framework. The rule cares that you have a plan and are executing it. The tier structure is how you make that executable for an office manager who does not have a compliance background.

What "reasonable and appropriate" means in enforcement

OCR does not expect a small five-provider practice to implement the same controls as a large academic medical center. The Security Rule explicitly accounts for the "size, complexity, and capabilities" of the covered entity (45 CFR § 164.306(b)(2)).

What "reasonable and appropriate" means in enforcement is: you identified your significant risks, you have a documented plan to address them, and you are making progress. A plan that identifies 10 gaps and has addressed 7 of them over 12 months is defensible. A practice with no plan, or with a plan that has not been touched in three years, is not.

Signing and dating the plan

Like the risk analysis, the risk management plan should be dated and signed (or attributed to a responsible party). The date tells investigators it is current. The signature tells them who is accountable.

If your risk management plan is a collaborative document, the practice owner's signature covers it. If an external consultant or IT vendor produced it, the plan should still be countersigned by someone inside the practice who reviewed and approved it — you cannot outsource accountability.

Keeping it current

When you complete your annual risk analysis, update the risk management plan to reflect:

• Risks that have been addressed and closed
• New risks identified in this year's analysis
• Updated timelines for open items
• Changes in responsible parties

The plan should be dated at each update. Investigators can tell the difference between a plan that has been maintained and one that was created once and filed.

---

Sources: 45 CFR § 164.308(a)(1)(ii)(A) (risk analysis); 45 CFR § 164.308(a)(1)(ii)(B) (risk management plan); 45 CFR § 164.306(b)(2) (flexibility of approach); HHS OCR Guidance on Risk Analysis Requirements (2010); NIST SP 800-30 Rev. 1 (2012).