BCP Change Management: The Product and Vendor Changes That Should Trigger a Mid-Cycle Continuity Review

TL;DR

• Annual board review of the BCP is the common practice examiners expect — and the FFIEC BCM booklet (November 2019) also expects the plan to reflect current operations whenever material changes occur.
• The 2015 predecessor booklet explicitly required BCP testing plan revisions for changes to vendors, outsourcing relationships, key personnel, and systems supporting critical functions.
• Mid-cycle BCP reviews should be scoped to the affected functions and dependencies — not a full annual rewrite, but a documented assessment of whether the change breaks the plan.
• Common exam finding: a BCP that accurately reflected operations twelve months ago but doesn’t reflect two core system migrations, three new vendors, and a product launch since then.

Your business continuity plan passed board approval in January. The Risk Assessment was updated. The BIA reflected your systems as of Q4 last year. Testing was documented and the results were solid. Board approved the presentation. Annual review done.

Since January, you’ve done three things that weren’t in that BCP:

You migrated the commercial lending platform to a cloud-hosted system from a vendor you didn’t have a contract with in December. You signed an agreement with a new fraud detection provider whose service interruption would halt card transaction authorization. And you launched a buy-now-pay-later product that runs on a third-party fintech platform whose name doesn’t appear anywhere in your current BCP.

The annual review is nine months away. None of those changes triggered a BCP update. That’s the gap examiners are finding.

What “Annual Review” Actually Means

The FFIEC Business Continuity Management booklet, issued November 2019, replaced the 2015 BCP booklet and shifted the framing from recovery to resilience. The primary change in expectation: recovering IT systems after an outage is no longer the goal. The goal is keeping critical business functions available. That’s a bigger ask, and it has direct implications for what a compliant BCP needs to reflect.

On maintenance and review: the booklet says BCM activities should be “reviewed periodically or as changes dictate” and that “Board minutes should reflect business continuity discussion (including credible challenges) and approvals.” Its examination procedures look for periodic board reporting with a written presentation covering the BIA, risk assessment, BCP, exercise and test results, and identified issues. Annual is the common practice. FDIC FIL-71-2019 transmitted the guidance to all supervised institutions.

Annual review is the floor. But the booklet also requires that management document, track, and resolve changes when updating the BCP and the exercise and testing program. Section VIII lists the triggers directly, including “Changes in enterprise strategies,” “New or reconfigured products, services, or infrastructure,” and “Changes in products and services offered by third-party service providers.” And VII.A says “Significant changes can render existing test plans obsolete, so BCP(s) should be retested soon after the change.”

The Federal Reserve’s SR 19-13 letter identifies maintenance and improvement as a core component of the BCM framework alongside governance, BIA, risk assessment, strategy, plan development, training, and exercises. Those components are interconnected: a system migration that changes your RTO profile, a new vendor that creates a new single point of failure, a product launch that adds a new critical function — these affect your BIA, your risk assessment, and your plan, all at once.

The annual review doesn’t capture that. That’s why mid-cycle reviews exist.

A Framework for Deciding What Triggers a Review

Not every change requires a full BCP rewrite. The trigger question is: does this change materially affect a critical business function, a critical dependency, or a documented RTO or RPO?

Category 1: Core system changes. Migration to a new core banking platform, replacing a loan origination system, moving to a cloud-hosted transaction processing environment. Any of these changes the technology stack your BCP was written against. The vendor, the recovery capabilities, the RTO assumptions, and the testing scenarios are all potentially stale the moment the migration is complete. This is a mandatory mid-cycle BCP review.

Category 2: New critical third-party vendors. A vendor is “critical” if its unavailability for the RTO window your BCP targets would materially disrupt a critical business function. Payment processors, core banking platforms, fraud detection services, cloud infrastructure providers, and core service providers typically qualify. Adding one — or replacing one — requires a BCP review to update vendor dependencies, confirm contractual recovery commitments, and assess whether joint testing has been scheduled.

The third-party BCP integration guidance from FFIEC covers what examiners expect from vendor contractual terms: notification timelines, testing requirements, RTO commitments, and documentation of how the vendor handles disruptions affecting multiple clients. If a new vendor relationship doesn’t include those terms, that’s a BCP gap from day one of the contract.

Category 3: New products that rely on vendor platforms. A buy-now-pay-later product running on a third-party fintech platform is a new critical dependency that didn’t exist when your BCP was last approved. If the platform goes down, customers can’t access credit at point of sale. That’s a business function disruption. The product isn’t in your BIA. The vendor isn’t in your dependency map. Your BCP doesn’t have a scenario for that platform’s failure.

Category 4: Significant personnel changes in critical BCP roles. The FFIEC guidance recognizes personnel changes as BCP review triggers. If your business continuity manager leaves, if a critical recovery role changes hands, or if significant restructuring affects who’s responsible for executing BCP activation steps, the plan needs to be updated to reflect current accountability.

Category 5: Mergers, acquisitions, and significant expansion. Acquiring a new business line, integrating an acquired institution, or significantly expanding into a new market — these affect your critical functions, your BIA assumptions, and your vendor dependencies in ways that require a systematic BCP review, not just a note that an acquisition was completed.

What a Mid-Cycle Review Actually Covers

A mid-cycle review isn’t a full annual rewrite. It’s a scoped assessment of how a specific change affects your BCP’s accuracy and your ability to meet your continuity objectives.

For a vendor change, the review covers: Is the new vendor in the BIA? Do we have the vendor’s RTO commitments in writing? Does our contract include notification rights when the vendor experiences an incident? Have we scheduled joint testing? What’s our fallback if this vendor is unavailable for our maximum tolerable downtime?

For a system migration, the review covers: Are the RTOs and RPOs in the BCP still achievable with the new system? Does the new system change our dependencies — do we now depend on a cloud provider we didn’t before? Has the testing scenario that covers this system been updated?

For a new product, the review covers: Does the BIA capture the customer and revenue impact of this product being unavailable? Is the vendor platform that runs the product reflected in our dependency map? Do we have a scenario for that platform’s failure?

The FFIEC BCM requirements post covers the baseline structure. A mid-cycle review produces documentation: a record that the change was assessed, what was reviewed, what was updated, and what was found to be current. Examiners check that management documents, tracks, and resolves changes when updating the BCP. That’s the paper trail they’re looking for.

The Concentration Risk Connection

Cloud provider concentration risk has been an examiner focus for two years. The BCP dimension of it is straightforward: if two new critical vendors you’ve onboarded since your last annual review both run on AWS, your BCP now has an undocumented single point of failure. Your existing BCP might have been written before either vendor existed. A mid-cycle review that assessed vendor changes would have surfaced the concentration issue.

This is also where the operational resilience critical service dependency crosswalk becomes a practical tool. When you add a vendor or a product, running it through the dependency crosswalk tells you whether it introduces new concentration risk or affects existing RTO commitments — before the BCP review, not after.

EU-regulated institutions face an additional layer: DORA’s ICT change management policy requirements include a proactive resilience impact assessment for material system and vendor changes before they go into production. That’s explicitly a pre-deployment requirement. Even for US-only institutions, the direction of travel in examiner expectations is similar — BCP maintenance shouldn’t be reactive to changes that already happened nine months ago.

What Examiners Are Finding

The most common BCP exam finding in the current cycle isn’t a failure of the annual review process. It’s a gap between the plan and operations that accumulated between annual reviews.

Examiners are asking for current vendor lists and comparing them to the BCP. They’re asking when critical vendors were added and whether there’s documentation of a BCP review at that point. They’re asking about new products launched since the last board review and whether those products appear in the BIA.

When none of those things match — when the vendor list has grown, the systems have changed, and the BCP still reflects last January — the finding isn’t that your annual review was inadequate. The finding is that you don’t have a change management process that connects operational changes to BCP maintenance.

That’s a different problem, and it requires a different fix.

So What?

The annual BCP review is necessary. It’s not sufficient.

The gap is a process gap, not a documentation gap. If your change management process — for vendor onboarding, for system migrations, for product launches — doesn’t include a step that asks “does this affect our BCP?”, changes will accumulate until the plan no longer reflects operations. By then, the annual review is catching up to a year of drift rather than confirming an accurate plan.

The practical fix: add a BCP impact question to your vendor onboarding checklist, your project management template for system migrations, and your product launch process. The question isn’t “does this require a full BCP rewrite?” The question is “does this change a critical function, a vendor dependency, an RTO assumption, or a concentration risk?” If yes, scope a review. Document it. Update what needs updating.

The BCP/DR Kit doesn’t have a separate change worksheet; changes land where they belong. Update the process row and its review date in the Business Impact Analysis tab, log what the change surfaced in Action Items with an owner and target date, and re-check Dependency Mapping for new RTO gaps.