BCP Update Triggers: When FFIEC Requires You to Revise Your Business Continuity Plan Between Annual Reviews

TL;DR

• The FFIEC BCM Handbook requires annual BCP review at minimum — but also mandates updates after significant operational, technology, and organizational changes
• Six specific triggers require mid-cycle BCP revision: organizational changes, technology migrations, vendor changes, live event activations, exercise findings, and material regulatory changes
• BIA updates and BCP updates are related but distinct — a dependency change in the BIA should cascade into a BCP update for affected functions
• Each update needs documentation: what changed, which sections were revised, who approved, and whether follow-up testing occurred
• The most common examiner finding: BCP documentation that doesn’t match the current operating environment

“We review our BCP annually” is a reasonable answer when an examiner asks about your program cadence. It becomes inadequate when that annual review happened in January, you migrated your core system to a new cloud provider in March, exited a critical vendor in April, and it’s now the end of June.

Annual review isn’t a ceiling. It’s a floor. The FFIEC BCM Handbook and ISO 22301 both build on annual review with a category of events that require mid-cycle updates regardless of where you are in the calendar. Most BCP programs know the annual cycle. Fewer have a documented trigger framework that tells them when the plan needs to be touched between cycles.

That gap is what examiners find.

What the FFIEC BCM Handbook Actually Says About Updates

The FFIEC Business Continuity Management Booklet — published as part of the IT Examination Handbook and available at the FFIEC IT Handbook website — is the primary reference for bank examiners assessing BCP programs. Its requirements on plan maintenance go beyond annual review.

The Handbook establishes that a BCP should be reviewed and updated when any of the following occur:

• Significant changes in the business environment, including mergers, acquisitions, divestitures, or strategic pivots
• Technology infrastructure changes, including migrations to new platforms, cloud transitions, or retirement of core systems
• Changes in key third-party relationships, including new critical vendor dependencies or exit of a vendor the plan relied upon
• A live activation of the BCP or any portion of it
• Findings from tests, exercises, or audits that identified gaps in the plan
• Material changes to the regulatory environment affecting operations

The Handbook also requires that updates to the BCP flow through the same governance process as the original plan — review by appropriate management, approval by senior leadership, and notification to the board or board committee with BCP oversight responsibility.

ISO 22301:2019 — the international standard for business continuity management systems — aligns with this framework. Section 10.2 requires organizations to review and improve the BCMS when “significant change” occurs, and Section 9.3 requires management review at planned intervals that capture these change triggers. For organizations pursuing ISO 22301 certification, an undocumented mid-cycle update process is a non-conformity.

The Six Triggers That Require a Mid-Cycle BCP Review

1. Organizational Changes

Mergers, acquisitions, divestitures, and significant restructurings change the business your BCP is designed to protect. When you acquire a new business unit, the BCP needs to incorporate that unit’s critical functions, recovery dependencies, and personnel. When you divest, sections of the plan that no longer apply need to be retired — leaving them in creates confusion during an activation.

Significant headcount changes in critical functions are also a trigger. The BCP identifies key roles and backup personnel. When the person holding a recovery-critical role departs or transfers, the plan needs to reflect who has actually been designated to fill it — not the person who was there when the plan was last formally reviewed.

Practical documentation: a change log entry identifying the organizational change, the sections revised, the revision date, and the approving manager. For significant structural changes (a merger or major acquisition), trigger a full plan review rather than a targeted section update.

2. Technology Infrastructure Changes

This trigger is the one most frequently missed at mid-cycle, and the one most likely to produce an examiner finding.

When a core system migrates from on-premises to cloud, the recovery procedures — RTO assumptions, recovery site configurations, backup procedures, vendor contacts, activation steps — may all need to change. If your BCP still describes recovery to a physical data center that no longer hosts your critical systems, the plan is documenting a recovery process that doesn’t exist.

Common technology triggers:

• Core system migrations (banking core, loan origination, payment processing)
• Cloud platform transitions or significant cloud configuration changes
• New application dependencies that are critical to primary business functions
• Retirement of legacy systems the plan relied on
• Changes to data backup architecture, frequency, or recovery capabilities

The BCP should reflect your actual technology architecture. When that architecture changes significantly, the BCP needs to keep pace.

3. Critical Vendor Changes

The BCP typically identifies critical third-party dependencies — vendors whose unavailability would trigger a business continuity response. When a vendor in that category changes, the plan needs to be updated.

New critical vendors: if you onboarded a cloud provider, payment processor, or technology platform that is now operationally essential, that vendor’s availability, recovery characteristics, and your response procedures when they fail need to be added to the plan.

Exited critical vendors: if you terminated a vendor that the BCP relied upon — and that dependency section wasn’t updated — examiners will find the mismatch when they compare your vendor inventory against your BCP.

Vendor infrastructure changes: if a critical vendor migrated their own infrastructure, changed their recovery architecture, or revised their SLA commitments, those changes affect the assumptions in your BCP. Annual vendor reassessments should include a specific question about changes that affect your business continuity assumptions.

This is also where BCP updates intersect with TPRM. When the vendor offboarding process closes out a critical vendor relationship, there should be a check: does this vendor appear anywhere in the BCP? If so, trigger a targeted BCP review. For more on the vendor exit process, see Critical Vendor Exit Planning: How to Build a Wind-Down Strategy Before You Need One.

4. Live Event Activations

When a business continuity event actually occurs — not a tabletop exercise, but a real activation — the BCP should be reviewed and updated afterward regardless of whether the response went well or poorly.

A successful activation reveals which procedures work as documented. An imperfect activation (which describes most real events) identifies gaps, assumptions that didn’t hold, communication flows that broke down, and decision trees that were unclear under actual pressure.

Post-activation review should be structured: what triggered the activation, which BCP sections were invoked, what worked as documented, what didn’t, and what changes are needed. The after-action findings should flow directly into a documented BCP revision.

For after-action documentation methodology, How to Write an After-Action Report for a BCP Exercise covers the template structure — the process applies equally to live events and exercises.

The OCC and FFIEC both expect that a live activation generates a lessons-learned process that results in plan updates. A bank that activated its BCP for a significant event and shows examiners an unchanged BCP from before that event has a documentation gap.

5. Exercise and Audit Findings

This trigger is written into most BCP programs in principle but often not enforced in practice. After a tabletop exercise or full simulation, the findings document identifies gaps. The plan update process that should follow frequently doesn’t — findings get logged, tracked, and eventually marked “closed” based on a conversation rather than a documented plan revision and follow-up test.

What the FFIEC expects:

1. Exercise findings are documented in a structured after-action report
2. The report is reviewed by appropriate management
3. Findings that require plan revision are tracked as open items with owners and due dates
4. The plan is updated based on the findings
5. The revised procedures are re-tested — either in the next scheduled exercise or, for material changes, in a targeted test before the next full exercise

The final step is the one most programs skip. Updating the plan document closes the finding administratively. Re-testing the updated procedures verifies that the fix actually works. Examiners specifically ask whether exercise findings were re-tested.

For the testing cadence that makes this cycle work, Annual BCP Testing Calendar: How to Schedule and Track Your Continuity Exercises covers scheduling structure and documentation requirements.

6. Regulatory and Compliance Changes

When a regulatory change materially affects how your institution operates or what it must be prepared to recover, the BCP should reflect those changes.

Recent examples that may have triggered BCP reviews:

• New notification requirements (FFIEC 36-hour computer security incident notification rule) that created obligations that must be woven into incident response and BCP workflows
• Cloud concentration risk guidance that required financial institutions to document exit strategies for critical cloud providers
• Operational resilience requirements from DORA or UK PRA guidance affecting entities with EU or UK operations
• Changes to liquidity requirements that affect treasury recovery procedures

The test for whether a regulatory change triggers a BCP review: does the new requirement create an obligation the BCP must reflect, either because the BCP addresses that process or because the new requirement creates a constraint (like a notification timeline) that affects how the BCP activation plays out?

The Documentation That Makes Mid-Cycle Updates Defensible

Each mid-cycle BCP update — however small — should generate a concise change record. What the record needs to contain:

The change record doesn’t need to be elaborate. A one-page entry in a BCP change log, attached to the revised plan, satisfies the documentation requirement. The absence of any change record — for a plan that hasn’t been updated since January despite three significant operational changes since then — is what examiners note.

Mid-Year Is a Natural Review Point

Late June is the practical mid-year checkpoint that most BCP programs should be conducting informally even if they’re not. Q2 just closed. Hurricane season opened June 1. Many organizations have completed their H1 tabletop exercises. This is the moment to ask:

• Has anything happened since January that should have triggered a BCP update?
• Does the BCP reflect our current vendor inventory, technology architecture, and critical personnel?
• Are there exercise findings from Q1 or Q2 that were documented but not yet incorporated?
• Are there regulatory changes effective in H2 2026 that need to be reflected in the plan?

The FFIEC BCM Handbook frames BCP maintenance as a continuous obligation, not an annual event. The annual review is the structured, comprehensive pass. Mid-cycle updates are what keep the plan accurate between those passes.

A BCP that’s accurate and current when an examiner arrives — or when an actual event requires activation — is the product of continuous maintenance, not an annual sprint. That maintenance starts with knowing what events require the plan to be updated.

So What?

The most common BCP program gap examiners identify isn’t that the plan doesn’t exist. It’s that the plan doesn’t match the operating environment it’s supposed to protect. Vendors that appear in the plan were exited months ago. Recovery procedures reference infrastructure that was migrated. Contact lists show personnel who left.

Those gaps don’t develop because program managers aren’t paying attention. They develop because most BCP programs have a clear annual review process and an unclear mid-cycle update process. Nobody knows exactly which events should trigger an update outside the calendar cycle.

Building a six-trigger framework — and making it part of how the TPRM program, IT project management, and organizational change management connect to the BCP — closes that gap before it becomes an exam finding.

For a BCP template built to the FFIEC BCM Handbook, including BIA, recovery procedures, exercise kit, and board reporting, the Business Continuity & Disaster Recovery (BCP/DR) Kit is designed to be updated throughout the year, not just at annual review.

Further reading:

• How Often Should You Update Your BIA? A Maintenance and Review Schedule
• ISO 22301 Documentation Requirements: What You Actually Need to Maintain
• Annual BCP Testing Calendar: How to Schedule and Track Your Continuity Exercises