How often to update a HIPAA risk analysis: what triggers it

How often must you update a HIPAA risk analysis?

The Security Rule sets no fixed interval for updating a HIPAA risk analysis. It requires a periodic technical and nontechnical evaluation under 45 CFR 164.308(a)(8), and it requires documentation to be reviewed periodically and updated in response to environmental or operational changes that affect the security of ePHI under 45 CFR 164.316(b)(2)(iii). If a customer, contract or OCR inquiry asks for proof of a current risk analysis, the question to answer is whether your records show a reevaluation that matches what has changed in your environment since the last one. The cycle itself is your decision to make and to defend, and it should follow from your systems, how quickly they change, and the triggers your own policies define, such as a new electronic health record module, a cloud migration, a merger, or a newly recognized threat.

An implementation partner can help you build the review calendar, the change log, the trigger criteria, and the dated records that show each reevaluation happened and what it changed. Only you, and the independent assessor you choose if you engage one, can state what that evidence shows about your actual risk. Keep the documentation for six years from its creation or last effective date, whichever is later, under 45 CFR 164.316(b)(2)(i). Plan for a stricter cadence as well: the January 2025 proposed rule (90 FR 898) would require a written risk analysis reviewed, verified and updated at least once every 12 months. That requirement is proposed, not final, and as of October 2026 it has not been adopted, so confirm its status before you write it into a policy as an obligation.

Confirm three things with your compliance lead before the next review cycle: which events in your environment count as triggers under your own procedures, who signs off on a reevaluation, and where the dated records are stored so they can be produced on request. A review that happened but cannot be shown with a date, scope and result is weak evidence for an auditor or OCR investigator. Guidance on the analysis itself appears in HHS OCR Guidance on Risk Analysis.

Which changes require a new evaluation of ePHI risk

HHS says an entity must assess whether its security environment has changed since the last evaluation, and the Security Rule ties reevaluation to environmental and operational change. The cards below are parallel triggers: each one changes the risk picture in a different way and points to a specific record that needs updating.

New or changed technology

A new EHR module, a cloud migration or a medical device that connects to the network changes where ePHI is stored, how it moves and who can reach it. Treat any new system that touches ePHI as a trigger. Check whether the new component is in the technology asset inventory, whether its access paths appear in the network map, and whether the risk register lists threats specific to it, such as unpatched device firmware or new internet exposure.

Newly recognized threats or vulnerabilities

A new vulnerability disclosure or a threat pattern affecting your software or sector can raise the likelihood of a risk you already rated as low. HHS's guidance describes reevaluation as needed when newly recognized risks to ePHI appear. Check whether the affected system is in scope, record the date you assessed the exposure, and update the likelihood rating and the risk management plan if the rating changes.

Security incident or breach

A security incident, a near miss or a confirmed breach shows that an assumed control did not work as the analysis expected. Reevaluate the affected systems and the controls that failed, then check whether related systems share the same weakness. Update the incident record, the risk analysis entries for the affected assets, and any corrective actions tracked in the risk management plan.

Change in organizational structure or ownership

A merger, acquisition, divestiture or reorganization can move ePHI into systems you did not previously assess, change who owns each control, or split one covered entity into affiliated parts. Confirm which entities and workforce groups now handle ePHI, whether shared services are in scope, and who holds responsibility for each safeguard. Update the scope statement, the responsibility matrix and the asset inventory.

New business associates or data flows

Adding a vendor that receives, stores or transmits ePHI creates new paths the analysis may not cover, including integrations, file transfers and support access. Each new data flow is a change in the security environment. Check that the business associate agreement is signed, that the flow appears in the data-flow map, and that the vendor's safeguards and access are evaluated in the risk analysis.

Change in locations or workforce model

Opening a site, moving to remote or hybrid work, or using new contractors changes the physical and access conditions that the analysis assumed. Staff working from home, shared locations or personal devices can create ePHI access points that were not in the original scope. Update the facility and workstation entries, the access inventory and the device records for each affected location or group.

Why the Security Rule uses reevaluation instead of a fixed interval

The Security Rule does not set a calendar interval for updating a risk analysis because it treats risk analysis as a continuing duty tied to how the organization changes. Under 45 CFR 164.308(a)(8), an entity must perform a periodic technical and nontechnical evaluation, and then perform another one in response to environmental or operational changes affecting the security of electronic protected health information. Section 164.306(e) adds that entities must review and modify security measures as needed and update the related documentation under 164.316(b)(2)(iii). The practical test is therefore not whether a date was met, but whether the analysis still matches the systems, vendors, workforce and threats the organization has today. Before you plan your next review, list what changed since the last analysis, such as a new electronic health record module, a new cloud region, an acquisition, or a vendor that now holds ePHI.

The rule is risk-based and scalable, which is why change rates differ so widely across regulated entities. A single-site practice with one practice management system and a small set of workstations may see few changes in a year, while a multi-state health system with hundreds of applications, hybrid networks and frequent clinical integrations may see changes every month. Section 164.306(b) lets each entity consider its size, complexity, capabilities, technical infrastructure, costs and the likelihood and impact of risks. Your review cadence should reflect those factors. Ask your security official to document the triggers you have agreed on, such as system changes, incidents, staff turnover in privacy or IT roles, and new regulatory or contractual obligations, so the trigger logic is visible before an assessor asks for it.

OCR evaluates whether an organization reviewed and updated its analysis in response to its own changes, so the decision record matters more than any single date. An investigator will typically ask for the analysis, the dates it was reviewed, what changed, who approved the update, and how the resulting changes flowed into the risk management plan. A well-kept log of review decisions, including reasons for choosing not to update after a change, can show reasonable diligence even when no formal update occurred. NIST SP 800-66 Rev. 2, published in February 2024, offers sample questions and key activities for this evaluation process. It is informational guidance only, not a binding standard, so use it as a checklist for your own reasoning rather than as a required method.

How to build a review cycle you can defend to OCR

This sequence turns the open-ended HIPAA duty to reevaluate risk into a documented cycle that an assessor can follow from the baseline analysis through every later version. Each step names the record it produces so the review history can be shown on request.

Establish the baseline risk analysis and date it
Complete a thorough, documented risk analysis covering all ePHI the organization creates, receives, maintains or transmits, and record the date it was finalized and who approved it. The baseline is the reference point every later evaluation is measured against, so it should list the systems, data flows, threats, vulnerabilities, current controls and likelihood and impact ratings in one signed document. Done means a dated, approved analysis exists and a copy is filed in the policy repository. The HHS free tool can help structure this work, but it does not replace the analysis.
Set a scheduled review point in written policy
Choose a recurring review interval that fits the organization's pace of change, then write it into the security management policy with the named owner, the scope of the review, and the sign-off authority. HIPAA does not prescribe a fixed interval, so the interval should reflect how often systems, vendors and staff actually change, and leadership should be able to explain why it was chosen. Ask counsel or a qualified consultant to confirm the interval against current guidance. Done means the policy states the interval and an assessor can see the first scheduled review on the calendar.
Define change triggers and the owner who assesses each
List the events that require an out-of-cycle evaluation, such as a new electronic health record module, a cloud migration, a new business associate handling ePHI, a significant incident, a merger, or newly recognized threats. Assign a named owner to each trigger, usually a system owner or the security official, who decides whether the change affects the security of ePHI. Recording the decision, even when the answer is no, shows the organization considered the change. Done means a trigger register exists with an owner and a decision record for every change logged since the baseline.
Update the analysis, risk plan and documentation after each trigger
When a trigger is confirmed, reassess the affected assets, threats and risk ratings, then update the risk management plan with any new or changed measures and revise the related policies, procedures and asset inventory. Record what changed, why, and who approved it, so the update is traceable to the event that caused it. Done means each confirmed trigger has a linked update record showing the revised risk rating, the measures added or retired, and the revised documents with new version numbers.
Retain every version for six years
Keep each completed risk analysis, its supporting records, and the superseded versions of related documentation for six years from the date of creation or the date it last took effect, whichever is later. Store them in a controlled repository with version history, access restrictions and a retention flag so nothing is overwritten or deleted early. Done means an assessor can ask for the analysis in force on any date within the retention period and receive the version that applied then, along with the change records that led to it.

Scheduled review, change-driven review, or both: which fits your organization

This table compares three ways to schedule HIPAA risk analysis updates: a fixed review cycle, reviews triggered by change, and a combined model. Read each row against your own environment, since the rule does not set a fixed interval and the combined model is the usual planning choice. Confirm your chosen cycle with counsel or an independent assessor before you rely on it.

Option	How it works	Evidence it produces	Main risk if used alone	When it fits
Scheduled review only	Reevaluation happens on a fixed calendar, such as yearly, regardless of what changed in the environment.	Dated review records, updated risk register, and signed sign-off showing the review occurred.	A major change, such as a new cloud region or vendor, can sit unassessed until the next scheduled date.	Organizations with stable systems, few vendor changes, and little new technology adoption.
Change-driven review only	Reevaluation occurs only when a defined event happens, such as new technology, a new system, a merger, or a newly recognized risk to ePHI.	Change tickets linked to reassessment records showing what changed and what was re-analyzed.	Without a periodic check, gradual drift and unrecognized changes can go unnoticed, and triggers may be missed.	Narrow environments where change is tightly controlled through a formal intake process.
Combined model	A scheduled periodic evaluation runs alongside defined triggers for environmental or operational change.	Calendar review minutes, change-triggered assessment records, and documentation updates with version history.	Requires discipline to keep triggers current and to define what counts as a material change.	Most organizations, including those with frequent cloud, SaaS, or vendor changes, because it covers both periodic and change-based duties.
Trigger examples to define	Typical triggers include adopting new software, moving ePHI to a new host, changing a business associate, or a security incident.	Trigger log showing each event, the owner, and the date the risk analysis was checked.	Vague triggers lead to inconsistent decisions and gaps in the record.	Any model; write triggers into the risk management procedure before they are needed.
Documentation retention	Each review, whether scheduled or triggered, produces documentation kept for six years from creation or last effective date, whichever is later.	Retained versions of the risk analysis and updates with dates and authors.	Overwriting prior versions removes the history an assessor will ask for.	Any model; confirm your retention system supports version history.
Proposed annual cycle	The January 2025 proposed rule would require a written risk analysis reviewed and updated at least every 12 months, but it is not final.	Annual verification records would be expected if finalized.	Planning only to an annual date may miss change-driven duties that apply now.	Organizations that want to prepare for the proposed change; the current rule does not set this interval.
Who decides the cycle	The organization sets its cycle based on risk, change rate, and documented rationale.	Written rationale for the chosen cycle and triggers, approved by leadership.	An undocumented cycle is hard to defend during an OCR inquiry.	Ask counsel or an independent assessor to review the chosen cycle against the current rule.

What the proposed annual review would change

The January 6, 2025 proposed Security Rule revision (90 FR 898) would replace today's event-driven update duty with a fixed cycle: a written risk analysis that is reviewed, verified and updated at least once every 12 months. It would also require a written technology asset inventory and network map to support that analysis. As of October 2026, none of this is law. The proposal has not been finalized, and the latest Unified Agenda entry for RIN 0945-AA22 lists the rule under Long-Term Actions with final action projected for July 2027. Until a final rule is published, the current requirements in 45 CFR 164.308(a)(8) and 164.316(b)(2)(iii) govern, and no fixed annual interval applies.

Building an annual review cycle now is low-cost planning, not a compliance claim. Practical steps include assigning a named owner for the review, setting a calendar reminder tied to the date of the last approved analysis, and recording what was checked, who verified it and what changed. An organization that already keeps its asset inventory and network map current will find a future rule easier to meet. The reader should not describe an annual review as current HIPAA law in policies, customer questionnaires or audit responses. Describe it as an internal practice that follows the proposed direction, and confirm the current obligations with counsel or the compliance lead.

Track the rulemaking in two places. The Federal Register proposed rule shows any comment history and the final rule when published. The Unified Agenda entry for RIN 0945-AA22 shows changes to the projected action date. Review both at least quarterly, and record the date you checked. If the final rule changes the interval, the verification scope, or the asset inventory requirements, update your review procedure and documentation before the effective date, and confirm with your auditor or counsel how transition timing applies to your organization.

Who owns each step of the risk analysis update

The covered entity or business associate must name a security official, and that person or function owns the risk analysis as a whole. The official decides when an update is triggered, judges whether the environment has changed enough to matter, approves the risk ratings and the risk management decisions that follow, and signs off on the revised documentation. Those decisions belong to the organization, and no outside party can take them over.

Trigger decisions: Decide whether a change such as a new system, a merger or a newly recognized threat requires a new evaluation under 45 CFR 164.308(a)(8).
Risk ratings and acceptance: Approve likelihood and impact ratings and record which residual risks leadership accepts.
Documentation sign-off: Approve the updated analysis and retain it for six years from creation or last effective date.
Workforce direction: Assign owners for each follow-up action and confirm they are completed.
Outsourcing scope: Decide what is handed to a partner or consultant and keep that scope in writing.

Check that your official can name the trigger events and the sign-off record for your last update.

Why risk analysis updates stall or fail review

Most HIPAA risk analysis updates fail for reasons that have little to do with technical skill. They stall at the annual calendar point, rely on an inventory nobody maintains, or leave no written trail of why decisions were made. The cards below cover the failure points an assessor or OCR investigator is most likely to find, with the fix and the record that shows the fix worked.

Updates only at the annual point

Teams often treat the risk analysis as a yearly project, so a new telehealth platform or a changed vendor goes unassessed for months. The Security Rule asks for periodic evaluation and for reevaluation when the security environment changes, which means mid-cycle events need their own review. Fix: write a short trigger list (new system, new vendor, new facility, a security incident) and require a dated review for each trigger. Record: a change log linking each trigger to the reevaluation that followed it.

Stale asset inventory

An analysis built on an outdated inventory describes systems that no longer exist and omits ones that do. Ask who owns each system and where its ePHI flows, then compare the inventory against cloud accounts, endpoints, and SaaS subscriptions at each review. Fix: assign an owner to the inventory and reconcile it against billing and identity records before the analysis starts. Record: a dated inventory with a version history and sign-off from the security official.

Decisions without written reasons

When a finding is accepted, deferred or closed, the file often says only the outcome. Under the addressable specification logic, an entity must document why an implementation specification is not reasonable and appropriate and what equivalent measure it uses. Fix: require a one-paragraph rationale for every accepted, deferred or closed finding, signed by the person with authority to accept the risk. Record: a decision log with the rationale, date, and approver for each entry.

Risk actions not tracked to completion

A risk analysis that identifies gaps is only half the work. Management actions often sit in a spreadsheet with no owner, due date or closure evidence, so the next analysis repeats the same findings. The risk management specification expects measures chosen to reduce risk to a reasonable and appropriate level. Fix: track each action with an owner, target date and closure test. Record: a closed-action register showing the test result that confirmed each reduction.

Overwritten documentation versions

Saving each new analysis over the old file erases the history an auditor or OCR investigator will ask for. Documentation must be kept for six years from creation or last effective date, whichever is later, and must be updated as the environment changes. Fix: store each version as a dated, read-only record and never overwrite a signed version. Record: a retained archive that shows what the analysis said at each point in time and when it changed.

Vendor and cloud changes missed

Moving ePHI to a new cloud region, adding a business associate, or switching a managed service provider changes the risk picture even when no internal system changes. These events are easy to miss because they are handled by procurement, not security. Fix: add a vendor and cloud change check to procurement and contract renewal steps, and route each change to the risk analysis owner. Record: a procurement checklist with a security review entry and the resulting reevaluation for each change.

Questions buyers ask about updating a HIPAA risk analysis

Does HIPAA require an annual risk analysis?

No. The Security Rule in effect today does not set a fixed interval for repeating the risk analysis. It requires a periodic evaluation under 45 CFR 164.308(a)(8), updates after environmental or operational changes, and regular reevaluation of potential risks to ePHI. The January 2025 proposed rule would require a written risk analysis reviewed, verified and updated at least once every 12 months, but as of October 2026 that change is proposed, not final. Plan to the current rule, and build an annual review into your program so you are ready if the proposal is finalized.

What counts as a trigger for updating a HIPAA risk analysis?

A trigger is a change that could alter the risks to ePHI. HHS says you should ask whether your security environment has changed since the last evaluation, for example through new technology or newly recognized risks. Typical triggers include:

Adopting a new system, application, cloud service or hosting provider that stores or transmits ePHI
Major network, identity or access model changes, or a move between on-premises and cloud hosting
A security incident, breach, or a newly disclosed vulnerability affecting your products or platforms
Changes in staffing, business associates, sites or the ePHI data flows you documented

Record each trigger and the date you assessed it, even when you decide no update is needed.

Must the whole risk analysis be redone after each change?

Not necessarily. The rule requires you to evaluate the effects of the change and update your documentation as needed, so the analysis can be revised where the change affects ePHI. In practice, you re-examine the assets, threats and vulnerabilities touched by the change and update the risk determinations and the risk management plan that depend on them. A full reassessment makes sense when the change is broad, such as a platform migration, or when earlier work was thin. Document the scope you chose and why, so an assessor can follow the reasoning.

How long must old risk analysis versions be kept?

Keep risk analysis documentation for six years from the date it was created or the date it last was in effect, whichever is later, under 45 CFR 164.316(b)(2)(i). Because each update can restart that clock, keep superseded versions, the change records that prompted them, and the approvals behind them. Store them somewhere that stays available to the security official and to the staff who need them, and confirm the retention arrangement with your legal or records team, since state law or contracts may require longer periods.

Does the free HHS tool handle update duties?

The HHS Security Risk Assessment Tool can support a risk analysis, but it does not replace the ongoing duties of review, reevaluation and documentation updates. It helps you work through questions and record results, while your organization still decides when to reassess and keeps the records current. Read the dedicated sibling topic on the SRA Tool for what it does and does not do and when a practice needs more than the tool.

How much effort does an update take, and who needs to be involved?

Effort depends on how many systems and data flows a change touches, how current your asset inventory is, and how much of the evidence already exists. The main work is updating the asset and ePHI data-flow records, reassessing affected threats and vulnerabilities, and revising the risk management plan. Involve the security official as the accountable owner, system and platform owners who know the configuration, IT operations for technical evidence, privacy or compliance staff for policy and breach implications, and leadership who approves risk acceptance. Ask any outside provider for a written scope and a clear list of the records they will need from you before quoting.

Can we update the risk analysis ourselves?

Yes, the Security Rule does not require outside help. An organization can run the update internally if its staff understand the rule, the threat landscape and its own systems, and if it keeps accurate records of the assets, data flows, decisions and changes. Many teams use an independent assessor for a periodic check of the work, because an outside view can catch gaps internal reviewers miss. Your choice should reflect the size of your environment and the skills you have in-house.

What can an implementation partner add, and what can it not do?

An implementation partner such as DeployOpen can prepare the systems and evidence an update depends on. Within a written, fixed scope, that can include configuring and documenting self-hosted open-source platforms inside your own infrastructure, producing logs and configuration records, and organizing the technical evidence for each change. A partner cannot make the risk decisions, which remain with your organization, and it cannot issue an attestation or certificate. Only an independent assessor can issue a third-party assessment report. There is no HIPAA certification, and HHS does not endorse private certifications.

How DeployOpen prepares risk analysis update evidence

DeployOpen helps organizations set up the review cycle, change triggers and documentation that show a HIPAA risk analysis stays current. The organization owns its risk analysis and its risk decisions, and DeployOpen prepares the systems, records and evidence that support them.

How we scope

The written scope names the systems, ePHI locations and change sources the update process will cover.
We agree which triggers, such as new technology or operational change, the organization will document and review.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before work starts.

How we build

We configure self-hosted open-source platforms inside your own infrastructure to log access and changes that feed each review.
We set up a documented review calendar and change-review workflow that records when the analysis was last evaluated.
We test that logs, asset records and change tickets are complete enough for an assessor to trace an update.

How we hand over

You receive documented procedures for periodic review, triggered reassessment and documentation updates with version history.
Retention settings are configured so update records are kept for the six-year period the rule requires.
Your security official and compliance team receive a walkthrough of the evidence and who signs off each update.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can review the update process when systems, vendors or ePHI flows change, within the agreed scope.
Confirm with your legal counsel and an independent assessor how often your organization's analysis must be updated.

How often to update a HIPAA risk analysis