FFIEC BCM Section III.B Risk Assessment: Turn Threats Into Continuity Strategies

TL;DR

• The BIA tells you what must recover and by when. The FFIEC BCM Section III.B risk assessment tells you what can break it, where controls are weak, and which continuity strategy is justified.
• Build a traceable chain: critical service → dependency → threat → control evidence → residual gap → strategy → test → remediation.
• A heat map is not the deliverable. The useful output is a set of decisions: what to prevent, what to recover, what to work around, what to accept, and what must stop safely.

A continuity risk assessment fails the moment it becomes a list of disasters with red, amber, and green boxes.

The FFIEC business continuity management Section III.B risk assessment is supposed to drive continuity strategy. That means a reviewer should be able to start with a critical service—ACH processing, card authorization, online banking, fraud monitoring—and follow the analysis all the way to a tested recovery decision. If the workbook ends at “cyberattack: high,” it has described anxiety, not managed risk.

The FFIEC Business Continuity Management booklet separates the business impact analysis from the risk assessment for a reason. The BIA establishes impacts and recovery priorities. Section III.B evaluates specific threats, vulnerabilities, and controls. The next step, continuity strategy, should be the consequence of that analysis rather than a menu copied from last year’s plan.

What is the FFIEC BCM Section III.B risk assessment actually for?

Its practical job is to answer five questions:

1. Which credible threats can disrupt each critical service?
2. Which people, facilities, technology, data, utilities, and third parties sit in the failure path?
3. Which preventive or detective controls genuinely reduce the exposure?
4. What residual gap remains if those controls fail or the event exceeds their design?
5. Which continuity strategy closes that gap within the BIA’s recovery objective?

That last question is where weak assessments disappear into the BCP. They score a ransomware event as high, list backups as a control, and never determine whether restoration can meet the four-hour RTO. Or they rate a telecom outage moderate because a branch has two circuits, without checking whether both enter through the same conduit.

The FFIEC Section III.B page is the regulatory anchor. For implementation detail, NIST’s Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1 provides a complementary system-contingency process covering BIA, preventive controls, recovery strategies, plan development, testing, and maintenance. NIST is not a substitute for FFIEC examination guidance, but the lifecycle is useful when Technology owns part of the evidence.

Keep the BIA and risk assessment separate—but connected

The fastest way to confuse both artifacts is to ask business owners to score threats while they are still defining impacts.

If your BIA needs repair first, use the BIA versus risk assessment guide before combining workshops. One practical aside: business owners usually want to discuss the outage they remember. Let them. Capture that event as evidence, then return to the structured dependency and threat review so one memorable incident does not become the whole assessment.

Build the traceability table before the heat map

A workable register needs enough structure to preserve the decision trail. Start with these fields:

Notice what is missing: a generic “mitigation” cell containing “BCP.” A plan is not a control merely because it exists. The control is the specific capability—an alternate circuit, immutable backup, manual queue, delegated authority, spare device pool—and the evidence that capability works.

Score controls from evidence, not confidence

Use a simple control scale if it helps consistency:

• Effective: designed for this failure mode, operating evidence is current, and the observed result met the objective.
• Partially effective: the control exists but testing found a capacity, timing, access, documentation, or dependency gap.
• Ineffective: the control failed, has no usable evidence, or does not address the stated threat.
• Not tested: do not quietly treat this as effective. Carry the uncertainty into residual risk.

These are assessment labels, not universal regulatory ratings. Define them in your methodology and calibrate them against your own exercise records. An anti-gaming check helps: every “effective” rating should map to a test record, production monitoring record, contract commitment, or independently reviewed operating artifact.

Work a threat all the way into a strategy

Realistic hypothetical: a community bank’s wire operations service has a four-hour RTO. Staff work from headquarters, but the wire application is remotely accessible. The assessment identifies a regional power and telecom event.

At first glance, remote access looks like the strategy. The dependency review changes the answer:

• Headquarters and the designated alternate workspace use different power utilities.
• Both locations rely on the same identity provider and the same telecom carrier.
• The backup approver has a laptop but has not authenticated from the alternate workspace.
• Call-back verification procedures exist only on the headquarters shared drive.
• The wire platform vendor’s status page is public, but the escalation contact is six months out of date.

The resulting strategy is not “work remotely.” It is a control package:

1. maintain an offline copy of the current wire procedure and call-back directory;
2. test backup approver access from the alternate workspace;
3. confirm the carrier paths do not share an unrecognized local failure point;
4. establish the vendor’s authenticated escalation route;
5. define a safe-stop rule when dual control or call-back verification is unavailable; and
6. run a timed exercise that measures access, approval, release, and reconciliation.

That is the link from threat to continuity strategy. It also exposes where ownership gets messy: Technology owns connectivity, Operations owns the manual procedure, Security owns emergency access, and Vendor Management owns provider evidence. The BCM owner should coordinate the record, not pretend to own every control.

For deeper dependency mapping, use the third-party dependency depth guide. It is especially useful when two “different” vendors share one cloud region, identity provider, telecom route, or subcontractor.

Turn residual gaps into test objectives

The FFIEC continuity-strategy section becomes operational when every material residual gap has one of four dispositions:

• Strategy funded and implemented. Record the owner, activation rule, capacity assumption, and evidence.
• Strategy approved but incomplete. Track the missing action and interim control as an issue.
• Risk accepted. Name the acceptance authority, rationale, scope, expiry, and reassessment trigger.
• Service restricted or stopped safely. Define who can make that decision and how customer, counterparty, and regulatory obligations are handled.

Then convert the uncertainty into a test objective. “Run ransomware tabletop” is too broad. “Demonstrate that Payments can retrieve the offline ACH release procedure, establish dual control, produce a balanced file, and document held items within four hours while primary identity services are unavailable” is testable.

The business continuity testing documentation guide explains the evidence package. At minimum, retain the scenario, assumptions, participants, timestamps, observed results, exceptions, owner decisions, and proof that remediation was later validated.

The examiner-ready evidence bundle

For one sampled critical service, be ready to produce:

• current BIA record and approved recovery objectives;
• dependency map with business, technology, facility, data, personnel, and third-party dependencies;
• threat-and-control assessment with methodology and evidence references;
• continuity strategy decision and approval;
• procedure or runbook implementing that strategy;
• latest exercise or test record with actual timing;
• unresolved exceptions, risk acceptances, and remediation status; and
• evidence that material changes triggered reassessment.

The full NIST SP 800-34 Rev. 1 PDF is useful for Technology teams building system-level contingency evidence. The bank-level record still needs to explain the business service and regulatory consequence. A clean server recovery test does not prove that Operations can reconcile queued payments or that Customer Support can communicate accurately during the outage.

So what?

Pick one service with a short RTO this week. Start at its BIA row and try to trace one realistic threat through dependencies, control evidence, residual risk, strategy, test result, and remediation. Every broken link is a concrete work item. That one-service trace will tell you more about the quality of the program than a perfectly colored enterprise heat map.

If the underlying artifacts are missing, the Business Continuity & Disaster Recovery Kit includes BIA, risk assessment, dependency mapping, recovery procedure, testing, and action-tracking templates built to work as one evidence chain.