The HIPAA Security Rule does not name a frequency for the risk analysis. There is no sentence in the regulation that says "annually," and any vendor or consultant who tells you the law requires a yearly risk analysis is overstating the text. What the rule does require is stricter in a different way: the analysis must be accurate, it must be thorough, and it must stay current as your organization changes. In practice, most organizations land on an annual review plus event-driven updates, and there are solid reasons for that pattern. This article walks through what the regulation says, where the annual convention comes from, and the specific events that should send you back to the document regardless of the calendar.
The short answer
| Question | Answer | Source |
|---|---|---|
| Does the Security Rule set a risk analysis interval? | No. It names no frequency | 45 CFR 164.308(a)(1)(ii)(A) |
| Is the risk analysis required at all? | Yes. It is a Required implementation specification | 45 CFR 164.308(a)(1)(ii)(A) |
| Must it be kept current? | Yes. Review and update in response to environmental or operational changes | 45 CFR 164.316(b)(2)(iii); 164.306(e) |
| Does anything require an annual cadence? | MIPS attestation is per performance period; the rule itself is not | CMS Promoting Interoperability requirements |
| Is annual review the common practice? | Yes, annual plus event-driven updates is the widely used benchmark | Industry practice; OCR enforcement patterns |
What the regulation says
Three provisions do the work here, and it is worth reading them together.
45 CFR 164.308(a)(1)(ii)(A) requires covered entities and business associates to "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information." This is a Required implementation specification. There is no flexibility about whether to do it, only about how.
45 CFR 164.306(e) requires security measures to be "reviewed and modified as needed to continue provision of reasonable and appropriate protection" of ePHI. The regulation's own maintenance clause: protection is judged against your environment as it exists now, not as it existed when the analysis was written.
45 CFR 164.316(b)(2)(iii) requires documentation to be reviewed "periodically" and updated "as needed, in response to environmental or operational changes affecting the security" of ePHI. Note the structure: periodic review is mandatory, and updates are tied to change, not to a date.
OCR's own guidance on risk analysis describes it as an ongoing process rather than a one-time exercise, and its enforcement history backs that up. Resolution agreements repeatedly cite organizations whose only risk analysis was years old or scoped to a single system while ePHI had spread to many.
Why annual became the benchmark
If the rule names no interval, why does everyone say annual? Four reasons, each real.
- MIPS and Promoting Interoperability. Clinicians in the Merit-based Incentive Payment System must attest to having conducted or reviewed a security risk analysis for each performance period. The performance period is a year, so for a large share of American providers an annual review is effectively mandatory even though HIPAA itself does not say so.
- Defensibility. When OCR investigates a breach, one of the first document requests is the risk analysis. A dated review from the last twelve months, with a remediation plan attached, answers the question cleanly. A four-year-old document invites the follow-up questions you do not want.
- Drift accumulates quietly. New laptops, a new e-prescribing vendor, a staffer who left, a portal feature switched on. None of these feels like a security event, and a year of them adds up to an environment the old analysis no longer describes.
- Budget cycles. Risk analysis findings feed remediation spending, and an annual rhythm lets findings land before budgets are set.
So the honest framing is that annual review is a convention that earns its keep, not a legal requirement. Treat it as the floor of a good program, with event-driven updates layered on top.
The events that should trigger an update
Between scheduled reviews, these are the changes that should reopen the analysis. Each one changes where ePHI lives or who can reach it.
- A new or replaced core system. An EHR migration is the obvious case, and the same logic covers practice management, billing, imaging, and backup platforms.
- A new location, a move, or a closure. Physical safeguards are part of the analysis, and they are site-specific.
- New vendors that touch ePHI. Every new business associate extends your risk surface beyond your walls.
- A security incident or breach. An incident is direct evidence about your vulnerabilities. Folding what you learned back into the analysis is both good practice and what investigators expect to see.
- Telehealth, remote work, or bring-your-own-device adoption. Each moves ePHI onto networks and devices the prior analysis likely never considered.
- Mergers, acquisitions, or new service lines. Inherited systems arrive with inherited risks, and they are yours the day the deal closes.
- Turnover in security-responsible staff. The Security Rule requires an identified security official; when that person leaves, the knowledge behind the analysis often leaves too.
What an update looks like in practice
An update does not mean starting over. A defensible update names what changed, assesses the risks the change introduces, records the decision, and carries a date and an owner. Three habits make the difference:
Keep the asset inventory live. The fastest way to check whether your analysis is current is to compare it against a list of every system that creates, receives, maintains, or transmits ePHI. If the list has entries the analysis has never heard of, you have your answer.
Date every revision. The documentation provision expects review you can demonstrate. An analysis with a visible revision history reads as a living process; a single undated PDF reads as a checkbox.
Close the loop on findings. A risk analysis that identifies gaps and then sits untouched is worse in an investigation than one that found less, because it proves you knew. Pair every finding with a remediation entry, even if the entry is a documented decision to accept the risk.
The proposed Security Rule changes
A proposed update to the Security Rule, published as a notice of proposed rulemaking in early 2025, would make review cadences more explicit, including more prescriptive expectations around risk analysis and its documentation. It is a proposal, not law, and its final content and timing are not settled. Nothing in it changes today's obligations. If it is finalized as proposed, organizations already running annual reviews with event-driven updates would be well positioned, which is one more argument for adopting that rhythm now.
A note for Washington organizations
Washington layers its own obligations on top of the federal floor. The state breach notification law, RCW 19.255, has a 30-day notification deadline that is shorter than HIPAA's 60 days, and the state Attorney General enforces both state law and, through federal authority granted to state AGs, HIPAA violations affecting Washington residents. A current risk analysis is the document that shows either regulator you were paying attention before the incident, not after it. For the mechanics of conducting one, see our step-by-step walkthrough; for scoping questions, risk analysis vs. gap assessment covers the distinction that trips up the most buyers.
Useful primary sources: the regulation text at 45 CFR 164.308 and 45 CFR 164.316, and the free HHS/ONC Security Risk Assessment Tool for small organizations doing the work themselves.