How often to update your HIPAA risk analysis (and why annual is the floor)

Update your HIPAA risk analysis at least once a year, and again immediately after any significant change to your environment — a new electronic health record (EHR), a new location, a merger, a security incident, or a major vendor change. The current Security Rule requires "periodic review" under 45 CFR § 164.308(a)(1)(ii)(A); the Office for Civil Rights (OCR) treats an analysis older than 12 months as presumptively stale, and the proposed update to the HIPAA Security Rule would write an annual floor into the text.

In every OCR settlement citing a risk analysis failure, the investigator notes the date. A risk analysis from 2019 is not current in 2026. A risk analysis completed before your last EHR migration does not reflect your present environment. The requirement at 45 CFR § 164.308(a)(1)(ii)(A) is for an assessment of risks you currently face — not risks you once faced. Annual review is a floor, not a ceiling: significant changes to your practice require immediate reassessment, not waiting for the calendar.

This article explains the timing requirements, what triggers out-of-cycle updates, and how to document your review cycle.

What the rule says

Current Security Rule (2005, amended 2013)

45 CFR § 164.308(a)(1)(ii)(A) requires covered entities to:

"Conduct an accurate and thorough assessment of the potential risks and vulnerabilities..."

The rule does not name a frequency, but it does not treat the analysis as a one-time task either. Two related standards require ongoing attention: § 164.306(e) requires covered entities and business associates to "review and modify the security measures implemented under this subpart as needed," and § 164.308(a)(8) requires a "periodic technical and nontechnical evaluation" in response to environmental or operational changes. Both standards date to the original 2003 Security Rule and were carried forward — and extended to business associates — by the 2013 Omnibus Rule. (The evaluation standard is a distinct requirement from the risk analysis itself; see risk analysis vs. periodic security evaluation.) The U.S. Department of Health and Human Services (HHS) issued 2010 guidance on risk analysis that describes it as an ongoing process to be revisited whenever the environment changes.

OCR enforcement interpretation

OCR's resolution agreements reveal the practical standard. When investigators find a risk analysis, they check:

• Date: When was this completed?
• Currency: Does it reflect current systems, vendors, and workflows?
• Review cycle: Is there a documented process for keeping it current?

Analyses older than 12 months are treated as presumptively stale. Practices have been cited specifically for documentation that was "not current" — a separate finding from "not accurate" or "not thorough."

The Risk Analysis Initiative settlements (2024–2025) emphasize currency. Several practices had analyses from prior years but were cited because they had not been updated to reflect current environments.

The proposed Security Rule update

The Notice of Proposed Rulemaking (NPRM) published January 6, 2025 (90 Fed. Reg. 898) would make the cadence explicit. Among its proposals is a requirement to conduct and review the risk analysis at least once every 12 months, and again whenever there is a significant change to the practice's environment or operations. It is still a proposal — not yet law — but it would codify the position OCR already takes in enforcement: annual review as the explicit floor rather than the implied minimum.

The annual cycle

For many small practices without major changes, an annual review is appropriate. The annual cycle should include:

Month 1: Schedule and prepare

• Calendar the analysis review
• Gather any documentation of changes since last analysis
• Verify system inventory is current

Month 2: Conduct review

• Validate prior findings (what has changed, what is still accurate)
• Assess new threats or vulnerabilities
• Update risk ratings based on current conditions
• Review and revise the Risk Management Plan

Month 3: Document and approve

• Date the updated analysis
• Obtain Security Officer attestation
• Distribute to relevant personnel
• Archive prior version

Documentation best practice: Keep version history. An investigator should be able to see that you conducted analyses in 2024, 2025, and 2026 — not just that you have a 2026 analysis.

Trigger events requiring immediate update

Annual review is the minimum. Certain events require out-of-cycle updates:

Technology changes

• New EHR or practice management system: The core system change affects the entire threat model
• New email or cloud platform: Changes transmission security and access controls
• New telehealth platform: Introduces new endpoints and vendor relationships
• New backup or disaster recovery solution: Changes data availability risks
• Significant network changes: New locations, VPN implementation, WiFi restructuring

Organizational changes

• New location or office: Expands physical security considerations
• Major workforce change: New roles, significant hiring or departures
• Merger or acquisition: Combines environments with different risk profiles
• Service line expansion: New procedures may mean new ePHI types or systems

Security events

• Breach or security incident: May reveal threats or vulnerabilities not previously assessed
• Audit or investigation finding: Requires validation that analysis addressed the area
• Ransomware or malware event: Demonstrates threat likelihood was higher than rated

Vendor changes

• New business associate: Requires business associate agreement (BAA) review and risk assessment
• Vendor security incident: Third-party breach may affect your risk rating
• Vendor service changes: New capabilities or discontinued features

Regulatory changes

• New OCR guidance: May change expectations for methodology or scope
• Proposed Security Rule update, if finalized: Would require gap analysis and potential control updates
• State law changes: California, Texas, or other state-specific requirements

Update vs. redo: determining the scope

Not every change requires starting from scratch. Determine whether to update or redo:

When to update (incremental)

• Minor vendor changes (version updates, not platform changes)
• Staff additions or departures in existing roles
• Confirmed accuracy of most prior findings
• New threat intelligence that affects ratings but not scope

Process: Review each section of prior analysis. Mark sections "validated – no change" or "revised – see below." Update affected sections only. Document what triggered the update.

When to redo (full analysis)

• Core system change (new EHR, email platform migration)
• New location or significant expansion
• Prior analysis found significantly inaccurate
• Major security incident revealing systemic gaps
• No analysis in 24+ months (too much change to track incrementally)

Process: Start from current environment inventory. Do not assume prior findings remain valid. Fresh assessment of threats, vulnerabilities, and risks.

Documenting the review cycle

OCR expects to see process, not just product. Your documentation should include:

The analysis itself

• Completion date
• Review due date (typically 12 months)
• Trigger events that would accelerate review
• Scope boundaries

Supporting records

• System inventory (current as of analysis date)
• Vendor list with BAA status
• Changes log (what changed since prior analysis)
• Methodology documentation

Version history

• Prior analysis dates and versions
• Summary of changes between versions
• Archive location

Example notation:

Risk Analysis v2026.1 — Completed May 15, 2026 Previous: v2025.2 — Completed November 10, 2025 Changes: Updated for new telehealth platform (Doxy.me added); revised likelihood ratings for ransomware based on industry threat intelligence; all other sections validated current.

Common timing mistakes

Mistake 1: The one-and-done analysis Completing a risk analysis in 2018 and considering the requirement satisfied. OCR settlements specifically cite outdated analyses.

Mistake 2: Undocumented updates Making changes to systems or vendors without updating the analysis. The practice knows the environment changed; the documentation does not.

Mistake 3: Calendar-only triggers Waiting for the annual review when a major change (new EHR, breach, new location) has already occurred. Trigger events require immediate response.

Mistake 4: No version history Keeping only the current analysis with no record of prior analyses or what changed. Version history demonstrates ongoing compliance.

Mistake 5: Update without revision Dating a new version without actually reviewing or changing content. OCR investigators read analyses; they can tell when findings are stale despite a recent date.

The practical workflow

For a small practice, maintaining current risk analysis is manageable with a simple system:

Calendar reminder: Annual review scheduled 11 months from last analysis (allowing time for completion before the 12-month mark)

Change log: Maintain a running list of system, vendor, and staff changes as they occur. Reference this during updates.

Trigger event protocol: When a major change occurs, calendar a risk analysis review for 30 days post-implementation.

Documentation template: Use a structured format that clearly shows what was validated unchanged and what was revised.

CoreFolio approach: The CoreFolio HIPAA assessment stores your prior answers and flags sections that may need review based on your change log. Re-assessment takes 20–30 minutes for annual updates, producing a new dated analysis with version history.

What "current" means to OCR

Current does not mean perfect. It means:

• Dated within the past 12 months (or since last significant change)
• Reflecting the systems, vendors, and workflows you actually use
• Incorporating current threat intelligence
• Connected to a current Risk Management Plan

An imperfect analysis from this month is more defensible than a perfect analysis from three years ago. The requirement is ongoing, not historical.

Sources