BCP Testing That Actually Satisfies Examiners: What the FFIEC Expects 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 describes what a meaningful exercise and test program looks like, and “annual tabletop” doesn’t appear anywhere in it. In fact, it says tabletops “by themselves” are “likely insufficient to validate recovery capabilities.”

Here’s what the booklet actually says — and what examiners are checking when they pull your test documentation.

TL;DR

• The FFIEC BCM booklet (2019) doesn’t set a fixed testing frequency — your own policy must “Establish minimum frequency, scope, and reporting requirements,” driven by your risk profile. Annual testing of critical functions is the common baseline examiners expect.
• The booklet’s four methods are full-scale exercises, limited-scale exercises, tabletop exercises, and tests (VII.G). Tabletops alone are “likely insufficient to validate recovery capabilities.”
• OCC Bulletin 2025-24 (effective January 1, 2026) is about community bank exam scope and frequency, not BCP. It doesn’t change the booklet’s testing expectations.
• Vendor testing is its own section (VII.I): participate in critical vendors’ testing and get the results
• 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 in November 2019, is organized into nine sections: business continuity management overview, governance, risk management (the BIA and risk assessment), continuity strategies, the business continuity plan, training, exercises and tests, maintenance and improvement, and board reporting. Exercises and tests get Section VII, the longest run of subsections in the booklet — and they’re how you validate that everything else works.

Across Section VII, the booklet expects a testing program that:

• Covers the “exercise and test universe” — VII.A describes it as “an inventory of all business processes and system components,” similar to an audit universe. You don’t test everything every year, but every critical process should be on the schedule.
• Uses different methods over time — VII.C suggests “A multi-year plan to execute the specific depth and breadth of exercises and tests to identify gaps in the program by using different methodologies and scenarios over time.”
• Produces documented results — VII.K says management “should document issues identified during exercises and tests and create action plans with target dates for resolving issues.”
• Results in remediation — VII.K also says management “should test corrective actions implemented as a result of a failed recovery objective or to address major issues encountered,” and document decisions to accept risks that aren’t remediated.
• Scales with risk — “The entity’s risk profile should influence the frequency, objectives, and documentation of the overall exercise schedule” (VII.A).

On frequency, the booklet puts the decision on you. VII.B says your policy should “Establish minimum frequency, scope, and reporting requirements,” and VII.A says exercises and tests should occur “at appropriate intervals, when new risks are identified, or when significant changes affect the entity’s operating environment.” The Appendix A examination procedures give an example of a coverage cycle: “all processes are covered annually or every three years.”

So “annual testing” isn’t an FFIEC mandate. It’s what most programs land on for critical functions and what examiners commonly expect to see, with more frequent testing for short-RTO or high-risk systems. If you’re a NYDFS-covered entity, the floor is firmer: 23 NYCRR 500.16(d) requires testing incident response and BCDR plans “periodically, but at a minimum annually.”

The Four Methods in VII.G — and When Each One Fits

Section VII.G says “The type or combination of methods should be determined by the entity’s size and complexity and the nature of its business.” It lists four.

Tabletop Exercises (VII.G.3)

The booklet defines a tabletop exercise (it notes it’s “sometimes referred to as a walk-through”) as “a discussion during which personnel review their BCP-defined roles and discuss their responses during an adverse event simulation.” Participants work through the plan in a conference room — who does what, when decisions get escalated, what happens if a key assumption proves 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.

The booklet is direct about the limits: “By themselves, tabletop exercises are likely insufficient to validate recovery capabilities, because they are limited to a discussion-based analysis of policies and procedures.” They won’t tell you whether your DR site works, your backups restore within RTO, or staff can execute procedures under realistic conditions.

A program that uses tabletops as its only exercise for critical systems is the classic setup for a finding.

Limited-Scale Exercises (VII.G.2)

“A limited-scale exercise is a simulation involving applicable resources (personnel and systems) to recover targeted business processes.” The goal is to determine “whether targeted systems can be recovered and whether personnel understand their responsibilities.” Think connecting to alternate systems, working from an alternate location, or switching to remote access for one department. This is where most programs should spend most of their critical-system effort.

The booklet notes the trade-off: limited-scale exercises “often have limited participation (e.g., departmental personnel only) or scope” and don’t necessarily show how systems and capacity would hold up across the enterprise.

Full-Scale Exercises (VII.G.1)

Full-scale exercises are “sometimes called a full interruption or comprehensive exercise.” One “simulates full use of available resources (personnel and systems) prompting a full recovery of business processes,” and its goal is “to determine whether all critical systems can be recovered at the alternate processing site and whether personnel can implement the procedures defined in the BCP.” These are the most operationally complex and disruptive — and the most valuable.

Tests (VII.G.4)

“Management uses tests to verify the quantifiable performance and reliability of system resilience.” Characteristics of a successful test can include “Validating RPOs, RTOs, and MTDs,” “Demonstrating recoverability at peak volumes,” and “Testing backup data to assess integrity and availability.” The critical word is quantifiable: if your core system has a 4-hour RTO and the only evidence is a vendor contract and a tabletop discussion, you have a testing gap.

Industry tests. Section VII.H covers industry exercises, and VII.J addresses core and significant firms. If you want a picture of what large-scale connectivity testing looks like, SIFMA’s industry-wide business continuity test — scheduled this year for Saturday, October 24, 2026, with the Futures Industry Association leading the futures component — has firms operate using backup sites, recovery facilities, and backup communications. It’s an industry exercise, not a regulator-run test.

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:

A common finding pattern: 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.

Section VII.I of the FFIEC BCM booklet is specific about vendor testing:

• Third-party service providers “should be included in the enterprise-wide exercise and testing program,” based on criticality
• “The right to perform or participate in testing with third-party service providers should be included in the contract”
• “Management should actively participate in the entity’s third-party service providers’ testing programs”
• “Management should request and receive test results and reports, remediation action plans and status reports upon their completion”
• “Management should track and resolve any issues identified during the exercise in a timely manner”

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.

A Note on OCC Bulletin 2025-24

You may have seen OCC Bulletin 2025-24 described as a BCP change. It isn’t. Its title is “Examinations: Frequency and Scope for Community Banks.” Issued October 6, 2025 and effective January 1, 2026, it removes “for community banks all requirements for examination activities set by OCC policy” — examples given include a fair lending risk assessment every cycle and flood insurance transaction testing — and lets examiners tailor scope based on each bank’s size, complexity, and risk profile. Community banks here means institutions with up to $30 billion in assets. The bulletin doesn’t mention business continuity.

It doesn’t change the FFIEC BCM booklet, and it doesn’t change what your testing program needs. The indirect effect is worth noting, though: when exam scope is driven by risk, your own documented rationale carries more weight. Three questions to be ready for:

Is your testing frequency documented and risk-justified? If you test quarterly, why? If you test annually, why? The decision should trace back to your BIA and risk assessment, which is exactly what VII.A and VII.B ask for.

Were testing decisions made intentionally? “We’ve always done it this way” isn’t a rationale. If your testing program hasn’t been revisited in three years, that’s the gap.

Is the testing proportionate to the risk? Proportionality means methods that actually validate recovery for the systems that matter, not a schedule 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 and location, method (tabletop, limited-scale, full-scale, or test), 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 treats exercises and tests 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 come through BCP examinations cleanly are the ones that can show: methods 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 testing program, the BCP/DR Kit’s Test & Exercise Log calculates whether each test met its RTO and RPO from the achieved results and flags overdue tests, the Scenario Library ties seven tabletop scenarios to the booklet sections each exercises, and the Tabletop Exercise Kit adds a facilitator guide, a scoring rubric and an after-action report template. The cadence defaults are template recommendations; set your own minimum frequency in policy, as VII.B expects.