Third-Party Dependencies in BIA: How Deep Should You Go?

The CrowdStrike outage on July 19, 2024 created an immediate BIA problem for financial institutions — not because CrowdStrike was in their BIA, but because it wasn’t.

Many banks had contracted with managed security service providers, endpoint security vendors, and IT service firms. Those Tier 1 vendors relied on CrowdStrike’s Falcon sensor for threat detection. When the faulty content update brought down 8.5 million Windows devices, the failure propagated through Tier 1 vendors into bank operations. Institutions that had only mapped their direct vendor relationships had an accurate picture of their compliance exposure — and a catastrophically incomplete picture of their operational exposure.

That’s the “how deep” problem in BIA third-party dependency mapping. Most BIAs document the obvious: your core banking provider, your payment processor, your cloud hosting vendor. What they miss is the layer below — where the real concentration risk lives.

TL;DR:

• One tier of third-party dependency mapping isn’t sufficient for critical business functions — FFIEC examination procedures require identification of single points of failure, which demands at least Tier 2 analysis
• The 2023 Interagency Guidance on Third-Party Relationships requires understanding risks from critical subcontractors, not just direct vendors
• Concentration risk is invisible at Tier 1 — multiple direct vendors relying on the same underlying provider creates correlated exposure your BIA won’t surface unless you go deeper
• Practical framework: Tier 1 for all vendors, Tier 2 for critical function vendors, Tier 3 only when concentration analysis reveals specific risk

Why Tier-1-Only BIA Dependency Mapping Fails

The standard BIA approach maps direct vendor relationships: you know your payroll processor, your core banking system provider, your card processor, your network carrier. You document what would be unavailable if each one failed. You set RTOs and RPOs. Done.

Except: your core banking vendor uses AWS us-east-1 as its primary environment, and your disaster recovery vendor also uses AWS us-east-1 as its failover region. Your “redundant” architecture has a single point of failure that’s invisible at Tier 1.

Or: your fraud detection vendor, your authentication provider, and your cybersecurity monitoring service all run on endpoint agents deployed by the same third-party security firm. One faulty update and three critical functions fail simultaneously.

The FFIEC Business Continuity Management booklet requires BIA identification of interdependencies — including third-party provider interdependencies and infrastructure concentration risks. The examination procedures specifically require identification of “single points of failure.” A single point of failure that exists at Tier 2 but is invisible at Tier 1 still creates a finding.

The Three-Tier Framework

Tier 1: Direct Vendors — The Minimum

Every BIA should document all direct vendors who support critical business functions. At this tier, you’re documenting:

• Which vendor provides the service
• Which business function(s) depend on it
• What’s unavailable if the vendor fails
• The operational and financial impact of the vendor’s failure
• Your vendor’s documented RTO/SLA vs. your required RTO
• Whether the vendor has an adequate BCP (separate from your BIA — but referenced in it)

This is the minimum that passes examination. For non-critical functions with easily substituted vendors, Tier 1 is sufficient. The analysis should still exist — you just don’t need to go deeper.

Tier 2: Critical Subcontractors — Required for Critical Functions

For functions designated as critical in your BIA, Tier 2 analysis means understanding which subcontractors your direct vendors rely on to deliver the critical portion of their service to you.

The 2023 Interagency Guidance on Third-Party Relationships from the OCC, FDIC, and Federal Reserve makes this explicit: institutions should “understand the risks posed by subcontractors” performing critical activities. For BIA purposes, this isn’t a full subcontractor audit — it’s targeted at subcontractors performing critical activities for your critical functions.

How to approach Tier 2 in practice: Ask your Tier 1 critical vendors three specific questions:

1. “What critical subcontractors does your delivery of [critical service] depend on?”
2. “Do any of those subcontractors have a single-provider relationship with you — meaning their failure would prevent you from delivering our service?”
3. “What cloud infrastructure or colocation providers do you rely on for the service components that support our critical functions?”

You’re looking for dependencies that, if they failed, would prevent your vendor from meeting their SLA with you.

Document these as Tier 2 dependencies in your BIA, with the same impact analysis: what’s the operational and financial impact if [Tier 2 subcontractor] fails, and how does that propagate through your Tier 1 vendor into your operations?

Tier 3 and Beyond: Concentration Analysis, Not Exhaustive Mapping

Going to Tier 3 or deeper is not about exhaustive mapping — it’s about concentration risk. The trigger for Tier 3 analysis is when your Tier 2 analysis reveals that multiple Tier 2 providers depend on the same underlying infrastructure, geographic location, or technology component.

The practical test: do your analysis across your Tier 2 providers and ask “is there any single provider, platform, or location that, if it failed, would bring down multiple Tier 2 dependencies simultaneously?” That’s your concentration risk indicator for Tier 3.

For most institutions, Tier 3 analysis surfaces in a small number of situations:

• Multiple vendors hosting on the same cloud provider AND same availability zone
• Multiple vendors using the same telecommunications carrier for core connectivity
• Multiple vendors operating from the same geographic region or data center campus

How to Scope Depth by Function Criticality

Not every business function needs the same depth of third-party mapping. Here’s a practical scoping framework:

For critical functions — payment processing, fraud detection, core banking, identity verification for regulated activities — go to Tier 2 systematically. For important functions, scope Tier 2 analysis to vendors where you’ve already identified that your direct vendor has no alternative provider for a critical component.

The Concentration Risk Overlay

Dependency mapping is vertical (Tier 1 → Tier 2 → Tier 3 within each vendor chain). Concentration risk analysis is horizontal — cutting across your vendor inventory to identify correlations.

After completing Tier 1 and Tier 2 mapping, build a simple concentration matrix:

If a single cloud region failure would bring down three critical functions simultaneously, that’s a concentration risk that needs to appear in your BIA — with an impact assessment treating the correlated failure as a single scenario, not three independent events.

This horizontal analysis is what most BIAs miss. They document vendor dependencies vertically (this vendor → these functions) without the cross-vendor view that reveals correlated failure scenarios.

Practical Data Collection: What to Ask Vendors

Getting Tier 2 dependency data from vendors requires explicit asking — most vendors won’t volunteer subcontractor information without being asked. Build these questions into your vendor onboarding due diligence and annual BIA refresh process:

For all critical vendors:

1. “What third-party providers do you depend on to deliver the service components that support our [specific critical function]?”
2. “Which of those providers, if unavailable, would prevent you from meeting your SLA commitments to us?”
3. “Do you have documented RTOs for scenarios where those subcontractors are unavailable?”
4. “What cloud infrastructure (provider, region, availability zone) does your service depend on for our critical function delivery?”

For vendors who won’t answer directly: Review the vendor’s SOC 2 Type II report — the complements user controls and subservice organization sections will typically list critical subservice organizations. Cloud providers will usually be named. This gives you a Tier 2 map based on independently audited information rather than vendor self-reporting.

For contractual leverage: Your vendor contracts for critical services should include a right to receive subcontractor information relevant to continuity planning and a requirement to notify you of material subcontractor changes. If your contracts don’t have this, flag it for the next renewal cycle.

Common BIA Third-Party Dependency Findings

Based on FFIEC examination patterns, these are the third-party dependency gaps most commonly cited:

Missing vendor dependencies entirely. The BIA references the critical function but doesn’t document which vendors support it. This happens most often for functions where the vendor relationship is old or taken for granted — the core banking provider that’s been in place for fifteen years doesn’t appear in the BIA because “everyone knows we use them.”

No impact assessment for vendor failure. The BIA documents that Vendor X supports Function Y, but doesn’t quantify what Function Y’s failure would cost — in revenue, in customer harm, in regulatory consequence. The FFIEC examination procedures specifically require that management be able to “determine the operational and financial impacts of a disruption.”

Tier 1 only for critical functions. The BIA maps direct vendors but doesn’t assess subcontractor dependencies for critical functions. Post-CrowdStrike, examiners are asking this question explicitly.

Concentration risk not identified. Multiple critical functions depend on the same underlying infrastructure, but the BIA treats them as independent scenarios. An examiner who maps the Tier 2 dependencies and finds a single point of failure that the institution didn’t document will write it up.

RTOs not validated against vendor SLAs. The BIA sets a 4-hour RTO for a critical function, but the vendor’s SLA allows 48 hours for incident resolution. The gap between your RTO and your vendor’s recovery commitment is a risk that belongs in the BIA — and an examiner who finds an untested gap will flag it.

Integrating Third-Party Dependencies With Your Recovery Strategy

The purpose of BIA third-party dependency mapping isn’t documentation for its own sake. It’s to drive recovery strategy decisions.

Third-party dependencies identified in your BIA should inform:

Contractual requirements. For critical Tier 1 vendors, do your contracts require them to have BCPs meeting specific standards? Do they require notification within your RTO window if the vendor has a disruption?

Alternative provider analysis. Where Tier 2 analysis reveals a critical subcontractor with no alternative, your recovery strategy should address the concentration — either by requiring the Tier 1 vendor to establish redundancy, or by developing a manual fallback process for the critical function.

Testing scenarios. Tabletop exercises for critical functions should include third-party failure scenarios that reflect the dependencies identified in your BIA. Testing that assumes all vendors are operational doesn’t validate your actual recovery posture.

Vendor concentration in risk appetite. Your board’s BCM risk appetite should address the level of third-party concentration that’s acceptable for critical functions. If you currently have three critical functions dependent on a single cloud availability zone, that’s a board-level discussion, not just a BIA notation.

So What? The Practical Minimum

For most institutions, the practical minimum for a BIA that passes examination and actually reflects operational reality:

1. Tier 1 for all vendors supporting any business function (critical or not)
2. Tier 2 for all vendors supporting critical business functions — specifically: ask for critical subcontractors and cloud/infrastructure dependencies
3. Concentration risk analysis across Tier 1 and Tier 2 — horizontal view to identify correlated failure scenarios
4. Impact assessment for each identified dependency — not just “Vendor X supports Function Y” but “Vendor X failure would cause $X in daily revenue loss, regulatory reporting failure within N hours, and customer impact across Y transactions”
5. Gap analysis between your RTOs and vendor SLAs — where there’s a gap, document it as a risk and address it in recovery strategy

The BCP/DR Kit includes a BIA dependency mapping template with Tier 1 and Tier 2 dependency matrices, a concentration risk analysis worksheet, and vendor SLA gap tracking — pre-built to the FFIEC BCM examination framework.

Related reading:

• Business Impact Analysis for Banks: FFIEC Requirements Explained
• BIA for IT Systems: How to Map Technology Dependencies to Business Functions
• How to Conduct a Business Impact Analysis: Step-by-Step Methodology