operational-resilience

Business Continuity Planning: What It Is, What Regulators Expect, and What Gets You Cited

Published: Last updated: Also known as: BCP

Business Continuity Planning (BCP) is the documented process by which a financial institution ensures critical compliance operations remain functional during disruptions. It's required under the EU Digital Operational Resilience Act (DORA), the FFIEC Business Continuity Management handbook, and FCA/PRA operational resilience rules including SS4/19.

What is Business Continuity Planning?

Business Continuity Planning (BCP) is the formal discipline of identifying a financial institution's critical operations, setting minimum service levels during a disruption, and documenting exactly how those operations will continue or rapidly recover when systems, staff, or facilities fail.

For compliance and risk teams, BCP is not a generic IT recovery document. It's a governance framework that covers the full disruption lifecycle: prevention, response, recovery, and review. An AML function's BCP must answer specific questions. If the transaction monitoring platform goes offline for 48 hours, who authorizes manual holds? How are SAR filing deadlines met? Who maintains the exception log until systems restore?

The control's scope spans three sub-components that are related but distinct. The Business Impact Analysis (BIA) identifies which processes are critical and assigns recovery time objectives (RTOs) and recovery point objectives (RPOs). The Business Continuity Plan documents the operational workarounds. The Disaster Recovery Plan (DRP) covers technology system restoration specifically.

BCP sits inside the broader operational resilience framework that regulators in the UK, US, and EU have made a board-level concern since 2021. The UK's PRA and FCA define operational resilience as an institution's ability to prevent, adapt, respond to, recover from, and learn from disruptions. BCP is the planning discipline within that framework: not a one-time document but an ongoing, tested program.

Regulators use Business Continuity Planning and Business Continuity Management (BCM) interchangeably. The terms refer to the same control.

Why is Business Continuity Planning required?

BCP is a regulatory requirement in every major financial jurisdiction, and the frameworks are overlapping. Examiners expect compliance with all applicable ones simultaneously.

In the United States, the FFIEC Business Continuity Management handbook is the foundational standard, requiring institutions to maintain a BCM program covering business impact analysis, annual testing, and board oversight. The OCC's Heightened Standards under 12 CFR Part 30, Appendix D require large national banks to maintain formal recovery programs. FinCEN's AML program requirements under the Bank Secrecy Act carry an implicit BCP obligation: the institution's AML duties don't pause during an outage, so the monitoring program must be able to continue or recover quickly.

In the European Union, the Digital Operational Resilience Act (DORA), which came into force on January 17, 2025, is the primary standard. DORA requires financial entities to maintain documented ICT business continuity policies, tested disaster recovery procedures, and annual reviews. It applies to banks, insurance firms, investment firms, crypto-asset service providers, and their critical technology vendors.

In the UK, PRA Supervisory Statement SS4/19 and the joint FCA/PRA policy statement PS21/3 require firms to identify important business services, set impact tolerances, and demonstrate they can remain within those tolerances during a severe but plausible disruption. Boards must approve the operational resilience framework annually.

The FATF Rec 1 (FATF) risk-based approach requires that risk controls be proportionate and maintained continuously. FATF Rec 10 (FATF) on customer due diligence and FATF Rec 11 (FATF) on record-keeping both require that AML controls and the records supporting SAR (Suspicious Activity Report) filings remain accessible and intact during disruptions. Loss of records during a system failure is a FATF compliance breach, not merely an IT incident.

What do regulators expect to see?

Examiners arrive with a checklist. BCP documentation is near the top.

A current, board-approved BCP. The plan must be dated within the last 12 months, approved at board level, and reflect the institution's actual operating model. Plans describing legacy systems no longer in use, or that predate a major acquisition, are immediate findings. "Current" means it was reviewed after every material change, not just on an annual calendar cycle.

A Business Impact Analysis with defined RTOs and RPOs. Specific recovery time objectives for each critical function are required. "Systems will be restored as soon as possible" fails the standard. A compliance function handling SAR filing should carry an RTO of 24 hours or less, given FinCEN's 30-day filing window and the practical need for buffer.

Evidence of annual testing, with results. The plan must be tested, not just documented. Table-top exercises, functional drills, and full disaster recovery failover tests all count, but examiners want a mix. They ask for test results, not schedules.

Remediation records from prior tests. If a 2023 test found the backup data center couldn't handle peak transaction volumes, examiners will ask what changed. Unresolved test findings are a red flag regardless of how well the current plan reads.

Third-party coverage. When Transaction Monitoring or Sanctions Screening are outsourced, the institution's BCP must address vendor failure. Examiners look for vendor BCP reviews, contractual SLAs covering recovery obligations, and documented fallback arrangements.

Staff awareness and training records. A BCP that only lives in a shared drive fails in a real incident. Role assignments and training completion records belong in the plan.

Board MI. Boards must receive BCP status reports at least annually, including test results, open issues, and any actual invocations of the plan during the year.

What does good Business Continuity Planning look like?

A mature BCP program is distinguishable from box-ticking compliance on several dimensions.

  1. Impact tolerances are set at the business service level, not the system level. The FCA/PRA framework asks institutions to define how long an important business service can be disrupted before customers or market integrity are harmed. That's a different question from "how long until the server is back." The best programs express tolerances in customer-facing terms: "customers cannot be unable to process a payment for more than four hours."

  2. Testing is adversarial. Best-practice programs don't design tests they know they'll pass. They use scenario-based exercises drawn from real events: the TSB 2018 IT migration failure that left 1.9 million customers without banking access, the RBS 2012 core banking outage that ran for weeks. The Basel Committee's Principles for Sound Management of Operational Risk explicitly requires firms to learn from both internal and industry events.

  3. Recovery and continuity are separated. Continuity planning covers what happens during an incident. Recovery planning covers restoration to normal operations. The best programs document both phases distinctly, with different owners, timelines, and success criteria.

  4. Third-party resilience is treated as first-party risk. Under DORA, institutions must assess the operational resilience of critical technology vendors as part of their own program. Concentration risk analysis is now expected: how many critical compliance functions depend on a single vendor, and what's the plan if that vendor fails?

  5. Compliance-specific scenarios are tested explicitly. Good programs include scenarios where AML monitoring, Customer Due Diligence, or SAR filing capabilities are unavailable. Manual workaround procedures are documented, including authorization chains for manual transaction holds and how exception logs are maintained during the outage window.

The FFIEC Business Continuity Management handbook is the most granular public standard for US institutions. The FCA/PRA PS21/3 policy statement is the definitive UK reference.

Common audit findings and exam citations

BCP is one of the most frequently cited controls in regulatory examinations. The findings cluster around predictable gaps.

Outdated or untested plans. Regulators at the FCA, OCC, and Federal Reserve consistently cite institutions for BCPs that haven't been updated after system migrations, acquisitions, or new product launches. A plan that names a decommissioned data center tells examiners the program is nominal, not operational.

No compliance-specific scenarios. Generic IT disaster recovery plans that don't address AML monitoring outages or SAR filing continuity are a finding on their own. FinCEN's AML program rules require a comprehensive program, and examiners read "comprehensive" to mean it survives disruptions intact.

Third-party blind spots. The Danske Bank 2018 enforcement action illustrated how operational failures at the subsidiary level can propagate into systemic compliance breakdowns across an entire group. Institutions that outsource core compliance functions without requiring vendor BCP reviews are cited repeatedly. After DORA, this gap is a primary examination focus for EU-supervised firms.

Single-vendor concentration. When one vendor provides transaction monitoring, screening, and identity verification, its failure is a single point of failure for the compliance program. The HSBC 2012 enforcement action demonstrated how systemic inadequacies in operational controls contribute to AML failures at scale. Regulators now ask specifically about vendor concentration risk and what the fallback plan is.

Superficial board engagement. Boards that receive a one-page "no issues" BCP update annually don't meet the standard. Examiners want evidence that boards have challenged assumptions, reviewed test results, and approved the impact tolerances themselves.

Incomplete invocation records. Every time the BCP is invoked, even partially, that event should be logged, reviewed, and used to improve the plan. Institutions with no invocation history, even after real incidents, draw examiner concern.

Metrics and KPIs

Measuring BCP health requires more than tracking whether the plan was updated on schedule. Compliance and operational risk teams should monitor the following metrics actively.

RTO achievement rate. In live tests and real incidents, what percentage of critical functions meet their defined RTOs? A program that routinely misses RTOs in tests but leaves the targets unchanged is not improving. Target: 95% or higher RTO achievement in annual DR tests.

RPO gaps. If the RPO for the transaction monitoring system is four hours, the backup data must be no more than four hours old at recovery. Measure the actual data lag in tests. Any gap against the defined RPO is a finding.

Test coverage percentage. What share of critical systems and business processes were tested in the last 12 months? 100% is the right target for Tier 1 critical functions. Under DORA, critical ICT systems require full DR tests annually.

Open findings from prior tests. Track the number of open remediation items from BCP tests, their age, and the percentage resolved within committed timeframes. More than 10% of items open beyond 90 days signals a governance gap.

Third-party BCP review completion rate. For each critical vendor, has an annual BCP review been completed and documented? Track completion against the vendor inventory. Below 90% completion is a finding under DORA for EU-regulated firms.

Plan review frequency. The BCP should be reviewed, and updated where needed, whenever there is a material change to systems, personnel, products, or operating model. Track the number of days since the last review and the trigger for that review. Annual calendar cycles without event-driven reviews are insufficient.

Invocation log completeness. How many partial or full BCP invocations occurred in the last 12 months, and does each have a documented post-incident review? Zero invocations on record, even after real disruptions, suggests the plan isn't embedded in operational practice.

How Business Continuity Planning connects to other controls

BCP is the operational safety net for the compliance control stack as a whole. When it fails, multiple controls fail simultaneously.

Transaction Monitoring is the most direct dependency. If an AML monitoring platform goes offline, transaction flows continue while the institution's detection capability pauses. BCP must define the manual escalation path, who holds authority to place manual holds, and how the backlog is cleared when systems restore. Without this, the institution is blind during the period it's most exposed.

Sanctions Screening carries the same dependency at higher regulatory risk. OFAC requires real-time screening. A BCP that doesn't address screening outages leaves the institution exposed to sanctions violations during the very window it's most operationally stressed. The Deutsche Bank 2017 enforcement action involved systemic control failures across multiple domains simultaneously. Institutions with weak cross-control coordination are consistently the ones where findings accumulate.

PEP Screening and Customer Due Diligence also need continuity provisions. Onboarding can't stop because a KYC system is offline. The BCP should document which risk-based exceptions are permitted during an outage and what enhanced review is required once systems restore.

From a typology perspective, operational outages create windows that bad actors exploit. Layering schemes sometimes accelerate transaction velocity during periods of market stress, when monitoring teams are stretched. Authorized Push Payment Fraud volumes often spike during system transitions and customer communication failures, precisely because customer confusion creates cover.

Record-keeping obligations under FATF Rec 11 (FATF) also tie directly to BCP: transaction records and compliance evidence must survive system disruptions intact, not be recoverable only after a forensic effort.

How FluxForce supports Business Continuity Planning

FluxForce maintains continuous AI-driven monitoring of compliance operations, so the surveillance layer doesn't depend on single-system availability. When primary systems experience degraded performance, FluxForce's agents continue processing transaction signals and flagging activity that meets escalation thresholds. Audit-ready decision logs sit in tamper-proof storage, so the evidence chain regulators require remains intact even during disruptions. Automated dashboards give compliance and operational risk teams real-time visibility into which controls are operating at full capacity and which require manual intervention, removing ambiguity about control status during an incident. Learn how FluxForce supports operational resilience.

How FluxForce strengthens Business Continuity Planning

FluxForce AI agents operate Business Continuity Planning in real time, capture audit-ready evidence automatically, and surface the gaps examiners cite before they become findings.

← Back to Controls