- Citation
45 CFR 164.308(a)(1)(ii)(B)- Standard
- Security management process, 164.308(a)(1)(i)
- Safeguard
- Administrative safeguards
- Type
- Required
What the rule says
Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).45 CFR 164.308(a)(1)(ii)(B), as currently in force
In plain English: Do something about what the risk analysis found. Decide which risks to reduce, how, by whom and by when, and then actually do it. Write that decision-making down.
What it means in practice
- Takes each risk from the analysis and assigns a treatment: reduce it with a control, accept it with a documented reason, or transfer it (insurance, a vendor).
- Has owners and dates. A plan with no names is a wish.
- Prioritizes by risk level, so the critical items happen first and the record shows that.
- Is tracked to completion, with evidence that the control went in.
- Is revisited when the risk analysis is updated.
Finding the holes was the easy part. That's the short version of this requirement.Your engineer
What OCR looks for
If an investigation touches this requirement, the data request will ask for some or all of the following.
- The risk management plan, mapped to the risk analysis findings.
- Tickets, change records or screenshots showing controls were implemented.
- Documented decisions to accept a risk, and who approved them.
- Status reporting to whoever owns security at the organization.
Where entities get caught
OCR settlements routinely cite the pair together: no risk analysis, and therefore no risk management. Where an analysis existed, the finding becomes 'failed to implement security measures sufficient to reduce risks', as in several 2024 and 2025 ransomware cases.
In April 2026 OCR signaled that it will look past whether a risk analysis exists to whether the entity acted on it. A known risk left on a list is harder to defend than one you never found.
How to meet it at a small organization
Keep it to one table: risk, level, decision, control, owner, due date, done date, evidence. For most small practices the first page is the same: MFA on email and the EHR, encryption on laptops, named accounts, screen locks, tested backups, BAAs signed. Finish those before anything exotic.
Under the proposed Security Rule update
The proposal would require a written risk management plan and would make the technical controls that typically populate it (MFA, encryption, segmentation, patching timelines) explicit requirements. The update was proposed in January 2025 and remains a proposal as of October 2026; see what's changing.
This page explains a federal regulation in plain language. It isn't legal advice, and AccuSights doesn't certify compliance; no one can. For every standard and specification, see the Security Rule, clause by clause.
With AccuSights: The fix list from your risk analysis becomes a tracked plan in the platform, with owners, dates and the evidence attached as each control goes in. Remediation is in-house, so the plan doesn't stall waiting for a second vendor.