BCP Testing That Actually Satisfies Examiners: What FFIEC Requires Beyond Your Annual Tabletop

Ask most compliance teams how their BCP testing program works and you’ll hear a version of the same answer: “We do a tabletop every year.” Follow up by asking what the tabletop found, and whether those findings were remediated, and the answers get less confident.

An annual tabletop that tests nothing hard, discovers nothing new, and generates no remediation work is not a BCP test — it’s an administrative exercise that creates the appearance of compliance without building any actual recovery capability. Examiners know the difference. The FFIEC Business Continuity Management (BCM) booklet is explicit about what a meaningful testing program looks like, and “annual tabletop” doesn’t appear anywhere in the description.

Here’s what the FFIEC actually requires — and what 2026 examiners are checking when they pull your test documentation.

TL;DR

• FFIEC BCM booklet (2019) requires testing frequency and type to be driven by risk — critical services must be tested at minimum annually, with more rigorous testing for higher-risk systems
• Four recognized test types: walkthrough, tabletop, functional, full interruption — only the first two can be done “from a conference room”; critical systems typically need functional or full interruption testing
• OCC Bulletin 2025-24 (effective January 1, 2026) eliminated prescriptive BCP policy requirements for community banks — but replaced them with the expectation that all testing decisions be documented and risk-justified
• Vendor BCP validation is a separate requirement — your RTO depends on your vendors’ recovery, and examiners are checking whether you’ve verified that
• Test reports without findings are a red flag, not a sign of a mature program
• The documentation gap is where most institutions fail: testing happened, nothing was written down in a format that demonstrates substance

The FFIEC BCM Booklet’s Testing Framework

The FFIEC BCM booklet, which replaced the 2015 Business Continuity Planning booklet, frames testing as one of five core BCM components: plan development, testing, training, maintenance, and governance. Testing is not optional or supplemental — it’s how you validate that the other four components work.

The booklet requires that testing programs:

• Cover critical business functions and supporting technology — you don’t test the full plan every year, but every critical system or process should be tested on a cycle driven by its risk profile and RTO
• Use multiple test methodologies — no single test type is sufficient for all scenarios; programs should use a mix of approaches appropriate to what they’re testing
• Produce documented findings — tests without written output have no evidential value in an examination
• Result in remediation — findings must be tracked and corrected, with the correction verified in a subsequent test or follow-up review
• Scale with the institution’s risk profile — community banks and large complex banks have different requirements, but the principle of risk-proportionate testing applies across the spectrum

For critical services, the expectation is annual testing at minimum. Systems with shorter RTOs, systems that change significantly between tests, or systems the institution’s risk assessment identifies as higher-risk may warrant more frequent testing.

The Four Test Types — and When Examiners Expect Each One

Walkthroughs (Desk Checks)

A structured review of the BCP document by the people responsible for executing it. Participants read through the plan, identify outdated information, note gaps or ambiguities, and confirm that procedures are current. Walkthroughs are appropriate for validating that a plan is up-to-date between more substantive tests — they are not a substitute for testing recovery procedures themselves.

A BCP program that uses walkthroughs as its primary testing mechanism for critical systems will generate a finding.

Tabletop Exercises

A structured discussion of a simulated disruption scenario. Participants work through the plan in a conference room setting — identifying who does what, when decisions get escalated, and what would happen if a key assumption proved wrong. Well-designed tabletops surface gaps in decision authority, communication procedures, and handoffs between teams. Poorly designed tabletops produce consensus that everything would go fine, which means the scenario wasn’t stressful enough.

Tabletops are appropriate for testing planning logic, decision-making, and communication. They’re not appropriate for validating that your DR site actually works, your backup tapes can restore to the expected RTO, or your staff can execute recovery procedures under realistic conditions.

Functional Tests

Functional tests activate actual recovery procedures for specific systems or processes without taking production offline. Staff use backup systems, validate that data replication worked, confirm that communications flow through alternate channels, and measure actual recovery times against RTO targets. Functional tests are the right level for most critical systems.

The critical word is “actual”: a functional test requires that something real is activated, not just discussed. If your core banking system has a 4-hour RTO and the only evidence of that is a vendor contract and a tabletop discussion, you have a testing gap.

Full Interruption Tests

Full interruption tests shift production operations to backup systems or alternate sites and run operations from recovery infrastructure for a defined period. These are the most operationally complex and disruptive test type — and the most valuable. They validate end-to-end recovery under conditions that approximate a real event: actual failover, actual data volumes, actual transaction processing, actual customer-facing impact assessment.

For systems where recovery failure would result in significant customer harm, regulatory exposure, or reputational damage, examiners expect evidence that full interruption testing has been conducted at least periodically. The OCC’s own industry-wide business continuity test, scheduled for October 24, 2026, is a full interruption exercise for options and futures infrastructure — and the precedent for what rigorous testing looks like.

For scenario design guidance, our 10 tabletop exercise scenarios covers how to build scenarios that are stressful enough to be useful.

What Examiners Actually Check in Your Test Documentation

When examiners pull your BCP test records, they’re not looking for a meeting agenda and a sign-in sheet. They’re looking for evidence that the test was substantive. The questions they work through:

The finding pattern examiners cite most often: a testing program that looks adequate on paper — annual tests, documentation on file — but produces no actionable findings and no evidence that anything was actually validated.

A realistic BCP test will find things. Systems don’t restore within their stated RTO on the first try. Staff don’t execute procedures correctly when they haven’t practiced them. Communication trees have outdated numbers. Data replication hasn’t been validated and is six months behind. These are normal test findings. Their absence is the red flag.

Vendor BCP Testing: The Gap Most Programs Miss

Your recovery time objective isn’t yours alone. If your core banking system has a 4-hour RTO and it runs on a third-party platform, that 4-hour RTO is entirely dependent on your vendor’s ability to recover within that window.

Most TPRM programs check that vendors have BCP plans. Far fewer validate that those plans actually support the institution’s RTOs.

The FFIEC BCM booklet is specific about what vendor BCP validation should include:

• Reviewing vendor-conducted test results, including what was tested and what failed
• Participating in vendor recovery exercises where possible
• Verifying that vendor RTOs align with the institution’s recovery requirements
• Following up on exceptions and gaps in vendor testing

A vendor that contractually commits to a 4-hour RTO but has never tested it is an undisclosed risk in your BCP. Examiners are checking whether institutions review vendor test results, note exceptions, and follow up — not just whether test results were filed.

This connects directly to the concentration risk problem: if your vendor’s backup infrastructure runs on the same cloud region as its production infrastructure, the vendor’s “backup site” fails in the same scenario that takes down primary operations. Our cloud concentration risk analysis covers how to evaluate vendor-level concentration in your BCP assumptions.

For software supply chain scenarios — how to test your recovery when a critical vendor fails, not just when your own systems fail — our software supply chain BCP testing guide covers the CrowdStrike scenario framework for exactly this problem.

OCC Bulletin 2025-24: More Flexibility, More Accountability

Effective January 1, 2026, OCC Bulletin 2025-24 eliminated mandatory policy-based examination requirements for banks under $30 billion in assets. The intent was to reduce administrative burden for community banks — examiners were spending significant exam time checking whether policy documents contained required sections rather than assessing whether risk management actually worked.

In the BCP context, this means examiners no longer check whether your BCM policy meets a format checklist. What they check instead:

Is your testing frequency documented and risk-justified? If you test quarterly, why? If you test annually, why? The decision needs to be traceable to your risk assessment. A bank with a straightforward technology environment and low operational complexity can defensibly test once a year. A bank with complex interdependencies, multiple critical systems, and short RTOs cannot.

Were testing decisions made intentionally? The bulletin elevated the importance of documented decision-making over policy compliance. “We’ve always done it this way” no longer satisfies the standard. If your testing program hasn’t been revisited in three years, that’s the gap.

Is the testing proportionate to the risk? Community banks have more flexibility in how they design their testing programs — but proportionality means testing that actually validates recovery capability for systems that matter, not testing that’s designed to check a box.

What a Defensible Test Report Looks Like

The most common documentation gap isn’t that testing didn’t happen — it’s that what happened wasn’t documented in a way that demonstrates substance.

A defensible BCP test report includes:

Header: Test date, type (walkthrough/tabletop/functional/full interruption), scenario description, scope (which systems, processes, or business units), and participants by name and role.

Scenario narrative: What disruption was simulated, what assumptions were made, and what constraints were set.

Timeline of events: What decisions were made during the test, in what order, by whom.

Findings: What worked as expected, what didn’t, what was slower than planned, what assumptions proved wrong. Tests without findings are not evidence of a mature program — they’re evidence that either the scenario was too easy or the documentation is incomplete.

Remediation tracking: Each finding gets an owner, a corrective action, and a target completion date. This section is what examiners use to verify that testing produces real improvement.

Sign-off: BCM program owner and a second-line governance reviewer.

A well-documented test with genuine findings and tracked remediation is far more defensible than a clean test report that raises the question of whether the scenario was realistic enough to produce any.

So What?

The FFIEC BCM booklet frames testing as the mechanism by which you validate that your BCP actually works — not the mechanism by which you document that a meeting occurred. Examiners have seen enough annual tabletops with no findings and no remediation work to know when they’re looking at theater versus substance.

The institutions that generate clean BCP examination outcomes in 2026 are the ones that can show: test types proportionate to criticality, scenarios designed to stress the plan, findings documented and traced to remediation, vendor recovery capabilities verified against the institution’s RTOs, and testing decisions documented with risk-based rationale.

If you’re building or refreshing your BCP testing program and need templates for test planning, scenario documentation, findings tracking, and vendor BCP validation, the Business Continuity & Disaster Recovery Kit includes a complete testing program structure with scenario libraries, test report templates, findings trackers, and vendor BCP validation worksheets — designed around the FFIEC BCM booklet’s examination expectations.