The HIPAA Security Rule contains two separate requirements that get collapsed into one. Risk analysis, at 45 CFR 164.308(a)(1)(ii)(A), is the assessment: a documented, accurate, and thorough look at the risks to electronic protected health information. Risk management, at 164.308(a)(1)(ii)(B), is the program: security measures sufficient to reduce those risks to a reasonable and appropriate level. The first produces a document. The second is supposed to keep operating after the document is filed. An organization that finishes its risk analysis, stores the PDF, and touches nothing until the next assessment has satisfied roughly half of what the standard asks.
The two requirements people conflate
Both specifications sit under the same standard, Security Management Process, and both are designated Required. Neither is addressable, so neither can be argued away with a documented rationale. The distinction matters because audits and breach investigations probe them differently. When the HHS Office for Civil Rights investigates a breach, its data requests routinely ask for the risk analysis and for evidence of how identified risks were handled afterward. A current analysis paired with an untouched remediation list answers the first request and fails the second.
Enforcement history bears this out. OCR resolution agreements have repeatedly cited failures "to implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level" as a distinct finding, separate from whether an analysis existed at all.
What the regulation text says
The risk management specification is one sentence: implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 CFR 164.306(a). The brevity is the point. The rule does not say how, how often, or with what tooling. It is technology neutral by design, and it scales its expectations through the flexibility-of-approach factors in 164.306(b): organization size, complexity, technical infrastructure, cost, and the probability and criticality of the risks in question.
What the text will not support is a purely calendar-based reading. Nothing in the rule suggests that risk drops to zero for eleven months after an assessment. HHS's own risk analysis guidance describes the process as ongoing and dynamic, revisited as the environment changes rather than on a fixed anniversary.
What an ongoing program looks like
In practice, organizations that treat risk management as a live program tend to have four things a point-in-time shop does not.
First, a remediation plan with owners and dates. Each risk the analysis identified is either accepted with a documented rationale or assigned to a person with a target date. Second, a change trigger: a defined set of events, such as a new system holding ePHI, a new location, a new vendor relationship, or a security incident, that reopens the analysis without waiting for the calendar. Third, evidence of activity between assessments: closed remediation items, updated policies, sanction actions, training records. Fourth, a standing owner. The Security Rule's assigned-security-responsibility standard already requires a named individual, and in working programs that person runs the risk register rather than merely signing the assessment.
None of this requires a particular product. A spreadsheet with owners, dates, and a review log can be a functioning risk management program. A polished annual report with no follow-through is not.
NIST SP 800-66: the closest thing to an official playbook
The Security Rule never mandates a framework, but HHS points implementers toward NIST Special Publication 800-66 Revision 2, which maps Security Rule standards to NIST's risk management concepts. SP 800-66 frames risk assessment and risk management as a continuous cycle: assess, respond to risks, monitor, and reassess when conditions change. For organizations that want a defensible answer to "what does ongoing mean," following the publication HHS itself cites is a reasonable position to take in front of any auditor.
What the proposed updates would change
The Security Rule updates HHS proposed in January 2025 would, if finalized as proposed, firm up the cadence question considerably: written risk analyses reviewed and updated on a defined schedule, along with more prescriptive documentation requirements across the rule. As of mid-2026 these remain proposals, not law, and organizations should not treat draft text as a current obligation. The practical takeaway cuts the other way: the direction of travel favors organizations that already run risk management as a standing program, because a formalized cadence would arrive as a documentation exercise for them rather than a rebuild.
A note for Washington organizations
Washington entities have a second reason to keep risk work current. The My Health My Data Act reaches consumer health data beyond HIPAA's boundaries, and the state Attorney General enforces both it and the state's data breach notification law, which carries a 30-day notification deadline, shorter than HIPAA's 60. A current risk register that covers where health data lives, HIPAA-regulated or not, is the working foundation for both regimes. Organizations that let the register go stale between annual assessments tend to discover their data map is wrong at the worst possible moment: during incident response.