Third-Party Dependent BCP: What FFIEC BCM and OCC 2023-17 Require You to Verify About Vendor Continuity

TL;DR

• FFIEC BCM requires institutions to assess the BCM capabilities of critical service providers — not just collect their documentation.
• OCC 2023-17 (interagency third-party risk management guidance) requires ongoing monitoring that includes BCP/DR assessment for critical activities.
• Three vendor failure modes — software update outages, counterparty insolvency, and shared telecom dependency — are consistently missing from institution BCPs even when vendor documents are on file.
• Examiners distinguish between having a vendor’s BCP and having verified it. The evidence they ask for — RTO validation, test results, subcontractor mapping — requires active review, not document collection.

In July 2024, a single faulty CrowdStrike software update took down an estimated 8.5 million Windows devices in hours. Banks, payment processors, and trading systems went offline. The institutions most affected weren’t ones that had failed to think about cybersecurity — they were ones whose BCP programs hadn’t accounted for simultaneous, instantaneous failure across every customer of a single vendor.

Two months earlier, Synapse Financial Technologies — a BaaS middleware layer that sat between fintech apps and their bank partners — had filed for Chapter 11. The ledger freeze that followed left thousands of customers unable to access funds for months. Institutions and fintechs using Synapse had vendor agreements. Some had vendor BCPs on file. None had a plan for “the middleware goes into bankruptcy and freezes account records.”

These failures share a pattern: institutions had vendor relationships documented. They may have had vendor BCP documents. What they didn’t have was a verified, tested understanding of what happens to their operations when each specific critical vendor fails in a specific way.

That gap — between collecting vendor continuity documentation and actually verifying vendor continuity capability — is where examiners are increasingly probing in 2026.

The Regulatory Framework: Two Documents That Say the Same Thing

The FFIEC Business Continuity Management booklet and the 2023 interagency third-party risk management guidance both create a third-party BCP obligation. They’re complementary.

FFIEC BCM Booklet

The FFIEC BCM booklet requires financial institutions to assess the BCM capabilities of their critical service providers as a component of the institution’s own BCM program. This isn’t limited to collecting a vendor document — the booklet requires institutions to understand vendor recovery capabilities in the context of the services the institution relies on.

Specifically, the booklet addresses:

• The need to consider third-party dependency in the Business Impact Analysis — mapping which business functions depend on which vendors, and what vendor failure would mean for the institution’s own RTOs
• Review of vendor BCP documentation for critical service providers
• Understanding vendor testing practices — when vendors last tested, what scenarios they tested against, and whether those scenarios are relevant to the institution’s service dependencies
• Contractual provisions for business continuity, including the right to review vendor BCP documentation and receive notice of material changes

The practical implication: the BCM booklet doesn’t treat vendor BCP as a due diligence checkbox at contract signing. It treats vendor continuity as an ongoing element of the institution’s own BCM program. Your BIA isn’t complete if it doesn’t account for what happens when your core banking vendor is down for 48 hours.

OCC Bulletin 2023-17 / Interagency Guidance

The 2023 interagency third-party risk management guidance — issued jointly by the OCC (Bulletin 2023-17), FDIC (FIL-29-2023), and Federal Reserve (SR 23-4) — requires ongoing monitoring of third parties throughout the relationship lifecycle. For critical activities, ongoing monitoring includes assessment of the third party’s financial condition, operational capability, and business continuity and disaster recovery capabilities.

The guidance explicitly states that ongoing monitoring for critical third parties should include reviewing the third party’s business continuity and disaster recovery plans and testing results. Not their BCP summary. Not their attestation that a BCP exists. Their plans and their test results.

This creates a specific evidence standard. An institution with a critical core banking vendor should be able to show examiners:

1. The vendor’s current BCP for the services the institution uses
2. The vendor’s most recent test results for those services
3. The institution’s analysis of whether the vendor’s RTO commitments are consistent with the institution’s own RTO requirements
4. Documentation of when this analysis was last updated

Three Vendor Failure Modes Most BCPs Miss

Most third-party BCP programs are structured around the scenario where a vendor experiences a natural disaster at a data center. That’s a legitimate scenario. It’s also the one vendors test against, and the one vendor BCPs are written to address.

The incidents that actually affected institutions in 2024-2025 followed different patterns.

Failure Mode 1: Simultaneous multi-customer software failure

The CrowdStrike July 2024 outage wasn’t a data center going offline — it was a software update that caused a boot loop on every affected Windows endpoint simultaneously. Every customer experienced the same failure at the same instant. Vendor geographic redundancy offered no protection. The vendor’s own BCP was tested against a different scenario.

Institution BCPs that relied on “vendor has a secondary data center” didn’t account for logic-level failures that affect all instances simultaneously. Any vendor deploying software to your environment can create this risk: endpoint protection, network monitoring, cloud backup agents, core system updates.

Failure Mode 2: Counterparty insolvency

When Synapse Financial Technologies filed for Chapter 11 in May 2024, the immediate problem wasn’t a technology failure — it was that account records sat in a system controlled by a company in bankruptcy proceedings. The ledger reconciliation dispute between Synapse and its bank partners took months to resolve, during which end users couldn’t access funds.

This is a fundamentally different BCP problem than “the vendor’s system is down.” The issue is: what happens to your obligations to customers when the vendor that holds records or processes transactions is in a legal proceeding that limits what the vendor can do?

Financial institutions and fintechs that used Synapse as middleware needed a plan for this. Most didn’t have one because vendor insolvency wasn’t in their BCP risk scenario inventory.

Failure Mode 3: Shared communications infrastructure dependency

The February 2024 AT&T outage that cut off voice and data services for millions of customers affected institutions’ primary and backup communication paths simultaneously — because both depended on the same underlying network infrastructure. Institutions with “call our backup telecom provider” in their crisis communications playbook discovered their backup provider used the same network for last-mile delivery.

This isn’t theoretical. It’s an infrastructure reality for most institutions. Vendor BCP programs that require calling the vendor through the same network that’s down don’t function in a shared-infrastructure outage.

Five Components of a Defensible Third-Party BCP Program

Here’s what distinguishes institutions that handle examiner questions about third-party BCP from institutions that generate findings:

Critical vendor inventory with RTO mapping

The FFIEC BCM booklet’s Business Impact Analysis requirements mean that your BIA needs to include vendor dependencies. For each critical vendor, map: which business functions depend on this vendor, what the institution’s RTO is for each function, and what the vendor’s stated RTO is for the relevant services.

If your institution’s RTO for payment processing is four hours and your payment processor’s RTO for your service tier is 12 hours, that gap is a BCP finding waiting to happen — regardless of whether you have the vendor BCP on file.

Documented BCP review, not BCP receipt

There’s a difference between having a document and analyzing it. Examiners know this. Document your review of each critical vendor’s BCP: what did you review, when, what the vendor’s RTOs are, whether you confirmed testing currency, and what gaps you identified.

If the vendor’s BCP doesn’t address the failure modes you’ve identified as relevant — software update failures, for example — that’s a finding in your own internal assessment, and you need a compensating measure: alternative vendor activation procedures, manual operating procedures, or other documented alternatives.

Test result review, not just attestation

The 2023 interagency guidance’s reference to “testing results” is specific. Vendor attestations that a test occurred don’t satisfy this standard. For critical vendors, request actual test summaries: what scenario was tested, when, what the results were, whether the tested RTO was achieved, and what remediation occurred when it wasn’t.

Vendors with mature BCP programs provide test summaries as a matter of routine. Vendors that resist sharing test results are telling you something about their testing program.

Subcontractor mapping

The nth-party risk problem extends into BCP. Your critical vendor may have a solid BCP. But if their own BCP depends on a subcontractor whose resilience you don’t understand, the BCP chain breaks. Ask: which of your subcontractors are critical to the delivery of our services? Are those subcontractors covered by your BCP testing?

This is where Synapse-style failures emerge. The institution’s BCP addressed the primary vendor relationship. It didn’t address the middleware provider’s dependencies.

Vendor-specific incident response procedures

For each critical vendor, document what your institution does when that vendor experiences an outage. Generic “contact the vendor” procedures don’t work in simultaneous multi-customer failures — the vendor’s support lines are flooded. Your procedures should specify: alternative communication paths, authority to activate manual operating procedures, client communication timing, and escalation contacts inside the vendor and inside the institution.

What Examiners Ask For

Based on examination guidance and common findings, here’s the evidence set that satisfies examiner questions about third-party BCP:

For each critical vendor:

• Current BCP documentation for the relevant services
• Date of institution’s most recent review of that documentation
• Institution’s analysis of vendor RTO vs. institution’s own RTO requirements
• Test results or test summary from the vendor’s most recent BCM exercise
• Date of most recent test and whether the tested scenario is relevant to the institution’s service dependency
• Documented institution response procedure for vendor failure scenarios

At the program level:

• A formal critical vendor inventory with business function mapping
• Policy and procedure governing how often vendor BCP documentation is reviewed and how review findings are documented
• Escalation matrix specific to vendor outage scenarios
• Evidence that vendor BCP requirements are included in contract negotiations, not just due diligence questionnaires

If you can’t answer examiner questions about vendor RTOs, testing currency, or your institution’s response procedure for vendor failure — and examiners are asking these questions — you have a documentation gap, not just a vendor management gap.

Where Fintechs and Community Banks Commonly Fall Short

Two patterns generate the most examination findings on third-party BCP:

Fintechs with bank partners: Fintech BCP programs often focus on the fintech’s own systems and overlook the bank partner relationship as a BCP dependency. If your BaaS sponsor bank experiences a disruption, what’s your customer communication protocol? How long can you operate without access to their systems? Have you discussed BCP coordination with your sponsor bank? This is a documented obligation in sponsor bank program agreements, and it’s a frequent finding in both OCC examinations of sponsor banks and state regulator examinations of fintechs.

Community banks with legacy vendor relationships: Community banks using core banking systems from legacy vendors often have long-standing relationships but outdated BCP documentation. The vendor BCP on file may be several years old, reflect an older service architecture, or predate material changes in how the bank uses the service. Annual review of vendor BCP documentation isn’t just good practice — it’s consistent with the FFIEC BCM booklet’s ongoing assessment requirement.

So What?

The practical regulatory standard is this: for each critical vendor, can you show an examiner what the vendor’s BCP says, when you last reviewed it, whether the vendor’s testing is current, and what your institution does when that vendor fails?

Collecting vendor documentation doesn’t satisfy that standard. Active review, RTO validation, and documented institution response procedures do.

Three questions to assess your third-party BCP program before the next examination:

1. For your most critical vendor — the one whose failure would most immediately affect your customers — can you name their RTO for your service and confirm their last test date?

2. Do your institution’s BCPs include vendor-specific response procedures, or generic “contact the vendor” escalation steps?

3. Has your BIA been updated to reflect vendor dependencies, with RTOs validated against vendor commitments?

For institutions building or updating their BCM programs against FFIEC requirements, the Business Continuity & Disaster Recovery (BCP/DR) Kit includes a Business Impact Analysis template with vendor dependency mapping, BCP documentation templates aligned to FFIEC BCM booklet sections III.B, IV.A, and VII, and a tabletop exercise kit for running vendor failure scenarios — available for $79.

Sources: FFIEC Business Continuity Management (BCM) IT Examination Handbook · OCC Bulletin 2023-17 — Third-Party Relationships: Interagency Guidance on Risk Management · FDIC FIL-29-2023 — Interagency Guidance on Third-Party Relationships: Risk Management · Federal Reserve SR 23-4 — Interagency Guidance on Third-Party Relationships · CrowdStrike — Preliminary Post Incident Review (PIR) July 2024