Your BCP Is a Document. The FFIEC BCM Booklet Wants a Management Process. Here's What Examiners Are Testing.

TL;DR

• The FFIEC’s Business Continuity Management (BCM) booklet shifted the examination standard from “do you have a plan?” to “does your management process work?” — and most fintechs and community banks haven’t made the same shift.
• The seven BCM components span governance, BIA, strategy, resilience planning, plan development, testing, and maintenance — and examiners look at all of them, not just the plan document.
• The most common gaps: BIAs that ignore cloud dependencies, RTO/RPO targets that have never been tested, BCPs that assume communications work, and annual tabletops that rubber-stamp a plan nobody has actually tried.
• “Your BCP exists” is not enough. Examiners want to see it tested, updated, and integrated into your risk management cycle.

There’s a version of business continuity management that most fintechs have: a PDF, a shared drive folder, maybe an annual tabletop exercise where everyone agrees the plan looks reasonable. The documents exist. They’ve never been tested in a way that would reveal whether they work.

Then there’s what the FFIEC Business Continuity Management booklet actually expects.

The shift from the old FFIEC Business Continuity Planning booklet to the current BCM booklet wasn’t cosmetic. The new name — management, not planning — reflects a substantive change in what examiners evaluate. Under the old model, the question was: do you have a BCP? Under the current model, the question is: does your BCM program function as an ongoing management process that would actually preserve critical services when something goes wrong?

For most institutions, the answer is closer to “we have a document” than “we have a management process.” That gap is what’s generating examination findings.

Why the Name Change Matters

The FFIEC IT Examination Handbook was updated in 2019 to rename its “Business Continuity Planning” booklet to “Business Continuity Management.” The handbook’s opening pages are explicit about why:

“Business continuity should not be focused only on the planning process to recover operations after an event, but rather it should include the continued maintenance of systems and controls for the resilience of operations, and should be incorporated into the risk management life cycle of all systems, processes, and operations of an entity.”

That’s a significant expansion of scope. Under the BCP model, an institution needed a recovery plan — steps to restore operations after a disruption. Under the BCM model, an institution needs:

• A governance structure with defined roles and board oversight
• A business impact analysis that maps every critical dependency
• Resilience strategies that allow critical services to keep running (not just recover faster)
• Plans that are tested and validated, not assumed to work
• A maintenance process that keeps everything current as the business evolves

The difference is the difference between a fire extinguisher and a fire prevention program.

The Seven BCM Components

The FFIEC BCM booklet organizes the program into seven core components, each with associated examination procedures.

1. BCM Governance

Examiners start with governance. This means: Who owns BCM at the board level? Does the board receive regular BCM reporting? Is there a BCM policy that’s been reviewed and approved? Is the BCM function staffed with people who understand the institution’s operations?

For fintechs — particularly those where the “business continuity team” is the head of engineering or a solo compliance hire — this is often where the first gaps appear. BCM governance doesn’t require a dedicated BCM officer at a small institution, but it does require explicit ownership, defined roles, and board visibility.

2. Business Impact Analysis

The BIA is the foundation of the entire BCM program. If your BIA is wrong, everything built on it is wrong.

The FFIEC expects a BIA that:

• Identifies all critical business functions (payments processing, customer service, regulatory reporting, etc.)
• Maps the dependencies for each function: people, technology systems, third-party services, physical facilities, and data
• Establishes Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each critical function
• Identifies the maximum tolerable downtime — the point at which a service disruption causes unacceptable harm to customers, counterparties, or the institution
• Is updated when operations, technology, or dependencies change

The cloud dependency gap. This is the most common BIA deficiency at fintechs in 2026. Cloud-native institutions often have BIAs that treat AWS, Azure, or GCP as background infrastructure rather than a critical dependency with its own risk profile. The 2024 CrowdStrike incident — which took down operations across financial institutions, including the communications systems staff would use to manage a response — made this gap visible in a way that’s now on every examiner’s checklist.

A defensible BIA names the cloud providers, the specific services (not just “AWS” but “AWS us-east-1 EC2, RDS, S3”), the impact of an outage at each level, and what backup or resilience strategy applies.

3. Strategy Development

Once the BIA establishes what needs to be protected and what the recovery targets are, the institution needs resilience and recovery strategies that actually achieve them.

Strategies can include: redundant infrastructure, failover to secondary environments, manual workarounds for automated processes, and geographic redundancy. The FFIEC expects strategies to be developed for both the institution’s own operations and its critical third-party relationships.

The examination question here is whether the strategies match the RTOs. If the BIA says payment processing must be restored within 4 hours, examiners want to see a strategy that actually achieves 4-hour recovery — not a strategy that works in 24 hours with a note that “we’re working on improving this.”

4. Resilience Planning

Resilience planning goes one step further than recovery planning: it’s about designing systems so that critical services can continue during a disruption, not just recover afterward.

For payment processors and fintechs with real-time obligations, this distinction matters. A payment institution whose systems go down for 8 hours may recover fully — but 8 hours of downtime in payments can trigger regulatory notification requirements, contract penalties, and customer attrition that aren’t solved by eventually recovering.

Resilience planning asks: which critical services cannot tolerate downtime at all, and what architecture, redundancy, or failover capability ensures they stay up?

5. Plan Development

This is the traditional BCP — the documented procedures for responding to disruptions. The FFIEC expects plans to be:

• Comprehensive: covering all critical functions identified in the BIA
• Actionable: written so that someone unfamiliar with normal operations could execute them
• Current: updated when systems, personnel, or processes change
• Accessible: available to the people who need them during a disruption, including offline

The communications assumption problem. Many BCPs have a fatal design flaw: they assume that the communications systems used to manage a response will be available during the disruption that requires a response.

The July 2024 CrowdStrike outage illustrated this precisely. Institutions whose operations went down also lost the Microsoft Teams instances their staff would use to coordinate response — because Teams ran on the same underlying infrastructure. The BCP said “teams will convene via [Teams/Slack/email]” and those tools were exactly what wasn’t available.

A defensible BCP designates backup communication channels that operate independently of the institution’s primary IT infrastructure: personal mobile phones with contact lists maintained offline, a designated external conference line, a messaging app on a separate platform, or radio communication for physical locations.

6. Training and Awareness

BCM training is often the first component to be cut from time-constrained compliance programs. The FFIEC expects it anyway, and for a practical reason: a plan that people haven’t reviewed and practiced produces worse outcomes than a plan people know.

Training expectations at a minimum: all staff with BCM roles receive training on their responsibilities; new staff are oriented to the BCM program; training is refreshed at least annually and when the plan changes.

7. Testing and Exercises, Maintenance, and Improvement

This is where most BCM programs fail their examination.

The FFIEC distinguishes between types of testing:

Tabletop exercises. A discussion-based exercise where participants walk through a scenario and discuss what they would do. Useful for identifying plan gaps and training participants on their roles. Not sufficient as the only form of testing.

Functional testing. Actually executing recovery procedures — failing over to backup systems, processing transactions through secondary channels, activating manual workaround procedures. This tests whether the strategies work, not just whether they’re documented.

Full-scale exercises. Comprehensive tests that simulate a real disruption, including communication failures, personnel unavailability, and system outages. Typically conducted less frequently but expected at least once every two to three years for institutions with complex operations.

The examination finding most frequently cited in the FFIEC examination procedures: tabletop exercises that don’t result in any findings or plan updates. An exercise that confirms everything is fine, with no lessons learned and no plan changes, typically signals to examiners that the exercise wasn’t rigorous enough to find anything.

Testing documentation needs to capture: the scenario, participants, results, findings, and corrective actions. Corrective actions need to have owners and timelines, and the plan needs to be updated before the next exercise.

RTO/RPO validation. The FFIEC expects that recovery time objectives established in the BIA have been validated through testing — meaning the institution has actually demonstrated it can meet its RTOs, not just documented that it intends to. Institutions with RTOs of 4 hours that have never run a failover test are a common examination finding.

What Examiners Actually Check

FFIEC examination procedures for BCM are publicly available in the IT Handbook InfoBase. The examination covers:

• Whether the board has approved the BCM policy and receives regular reporting
• Whether the BIA identifies all critical functions and their dependencies, including cloud and third-party
• Whether RTOs and RPOs are established and have been tested
• Whether the plan covers all critical functions identified in the BIA (gaps between the BIA and the plan are a finding)
• Whether the testing program includes functional tests, not just tabletops
• Whether testing results in documented findings and plan updates
• Whether succession plans exist for key BCM personnel
• Whether third-party BCPs have been reviewed and are integrated into the institution’s plan
• Whether the BCM program is updated when the business changes

This is not a short checklist. An examiner spending time on BCM will ask for: the BIA, the risk assessment that feeds it, the BCM policy, meeting minutes from BCM governance reviews, testing documentation with lessons learned, plan update logs, and evidence of board reporting.

The Third-Party BCP Gap

One of the most commonly overlooked components: your critical vendors’ BCPs.

OCC Bulletin 2023-17 (interagency third-party risk management) explicitly expects banks and their service providers to have BCPs, and expects institutions to review their critical third parties’ BCPs as part of ongoing oversight. For fintechs, this means reviewing the BCPs of core banking providers, payment processors, data centers, and cloud providers.

Reviewing means actually reading the BCP, assessing whether the vendor’s RTOs and RPOs align with your institution’s requirements, and documenting that you did it. “We asked for it and it exists” is not the same as “we reviewed it and it meets our needs.”

If a critical vendor’s BCP shows a 24-hour RTO and your institution needs that vendor’s services restored within 4 hours, that’s a contractual gap and a risk finding — whether or not it’s in your own BCP.

A Self-Assessment: Where Does Your Program Stand?

So What?

The FFIEC BCM examination is a full-day conversation about whether your program actually works — not whether the document exists. The shift from planning to management means every component gets evaluated: governance, analysis, strategy, testing, and continuous improvement.

Most fintechs and community banks are somewhere in the middle. They have a document, probably an annual tabletop, maybe a vendor BCP folder somewhere. That’s a starting point, not a passing grade.

The concrete action: identify which of the seven components has the most significant gap in your program and fix that one before your next exam. For most institutions, it’s either the BIA (cloud dependencies not mapped) or testing (only tabletops, no functional failover). Those two fixes close the majority of examination findings.

The Business Continuity & Disaster Recovery Kit includes a BIA template with cloud dependency mapping, recovery strategy worksheets, a 58-item pre-launch checklist for BCM program implementation, and four worked examples covering payment processor outage, ransomware, cloud provider failure, and hurricane/physical facility loss — structured to match the FFIEC BCM booklet’s examination framework.

Related reading:

• FFIEC BCM Section III.B: Risk Assessment and Continuity Strategies
• Cloud Concentration Risk in Your BCP: What AWS Outages Mean for Fintech FFIEC Compliance
• BCP Testing: What FFIEC Examiners Expect in 2026