What Is Business Continuity Management?

Business continuity management is the structured process through which an organization prepares to maintain or restore critical activities following disruption.

It typically includes:

1. Governance

2. Business      impact analysis

3. Threat      and risk assessment

4. Continuity      strategies

5. Business      continuity plans

6. Crisis-management      procedures

7. Technology      disaster recovery

8. Communications

9. Training

10. Exercises      and testing

11. Plan      maintenance

12. Post-incident      improvement

A business continuity plan generally documents the procedures and resources required to sustain or recover operations following a significant disruption. NIST describes such a plan as a predetermined set of instructions for sustaining business processes during and after disruption.

Business continuity may address events such as:

• Technology      outages

• Cyberattacks

• Loss      of premises

• Staff      unavailability

• Utility      failures

• Telecommunications      failures

• Natural      disasters

• Civil      emergencies

• Vendor      failures

• Data      corruption

• Public      health events

• Payment-network      disruption

• Banking-partner      failure

The plan should be sufficiently detailed to support action but sufficiently practical to use during a real emergency.

What Is Operational Resilience?

Operational resilience is the organization’s ability to continue delivering important services through disruption.

It focuses on the external outcome of the service rather than solely on the recovery of individual internal systems.

An operational resilience framework commonly includes:

• Identification      of important business services

• Impact      tolerances

• End-to-end      service mapping

• Vulnerability      assessment

• Scenario      testing

• Remediation

• Incident      response

• Communications

• Governance

• Continuous      improvement

This service-based perspective is especially important in financial services.

Restoring a technology platform does not necessarily mean that the customer service has been restored.

The organization may also need:

• Staff

• Data

• Authentication

• Payment      connectivity

• Banking      access

• Liquidity

• Customer      communications

• Fraud      controls

• Reconciliations

• Third-party      support

Operational resilience therefore requires the organization to examine the complete chain of resources needed to deliver the service.

Business Continuity vs Operational Resilience

Business continuity and operational resilience are complementary.

They should not be treated as competing frameworks.

Business Continuity

Business continuity typically focuses on:

• Critical      business processes

• Recovery      procedures

• Alternative      working arrangements

• Technology      recovery

• Crisis      response

• Recovery      objectives

It asks:

How will the organization continue or recover this activity?

Operational Resilience

Operational resilience typically focuses on:

• Important      services

• Customers      and markets

• Tolerable      disruption

• End-to-end      dependencies

• Severe      but plausible scenarios

• Vulnerability      remediation

It asks:

Can the organization continue delivering this important service without causing intolerable harm?

Business continuity plans are one of the principal tools used to achieve operational resilience.

However, the organization may have detailed continuity plans and still lack resilience if:

• Important      services have not been identified.

• Dependencies      are incomplete.

• Recovery      objectives are not connected to customer harm.

• Plans      have not been tested end to end.

• Vendor      failure has not been considered.

• Recovery      cannot occur within acceptable limits.

Business Continuity vs Disaster Recovery

Business continuity and disaster recovery are also related but distinct.

Business Continuity

Business continuity addresses how the organization maintains or restores business activities.

It includes:

• People

• Processes

• Premises

• Technology

• Data

• Vendors

• Communications

• Decision-making

Disaster Recovery

Disaster recovery generally focuses on restoring technology, systems, applications, infrastructure and data.

It may include:

• System      restoration

• Data      recovery

• Backup      environments

• Network      recovery

• Cloud      recovery

• Database      restoration

• Technical      failover

Technology recovery is essential, but it is only one part of business continuity.

A technically restored system may still be unusable if:

• Employees      cannot access it.

• Data      is incomplete.

• Interfaces      remain unavailable.

• Vendors      have not recovered.

• Customer      authentication fails.

• Operational      reconciliations cannot be completed.

Governance and Accountability

Business continuity and operational resilience should be supported by clear governance.

The framework should define:

• Board      oversight

• Senior-management      accountability

• Framework      ownership

• Business-service      ownership

• Process      ownership

• Technology      responsibilities

• Crisis-management      authority

• Incident      escalation

• Plan      approval

• Testing      responsibilities

• Reporting

• Risk      acceptance

The board and senior management should understand:

• Which      services are most important

• The      organization’s principal vulnerabilities

• Whether      impact tolerances can be met

• The      status of remediation

• Major      vendor dependencies

• Significant      incidents

• Testing      outcomes

• Unaccepted      residual risks

Operational resilience should not be delegated entirely to information technology or risk management.

Business owners are responsible for understanding the complete service and the consequences of its disruption.

Operational Resilience Policy

An operational resilience policy may define:

• Purpose

• Scope

• Governance

• Important-business-service      methodology

• Impact-tolerance      methodology

• Mapping      standards

• Scenario-testing      standards

• Vulnerability      management

• Incident      management

• Communication

• Third-party      expectations

• Reporting

• Review      frequency

• Record      keeping

The policy should connect with related frameworks, including:

• Enterprise      risk management

• Operational      risk management

• Business      continuity

• Technology      risk

• Cybersecurity

• Vendor      risk management

• Incident      management

• Crisis      management

• Change      management

• Safeguarding

• Regulatory      reporting

Policies should establish expectations, while detailed procedures should explain how the framework operates.

Business Continuity Policy

A business continuity policy may address:

• Roles      and responsibilities

• Business      impact analyses

• Risk      assessments

• Recovery      strategies

• Plan      standards

• Crisis      activation

• Escalation

• Communications

• Technology      recovery

• Vendor      continuity

• Testing

• Training

• Plan      maintenance

• Lessons      learned

The organization should define which business units, entities, offices, products and outsourced activities are included.

A group-level plan may not adequately address the legal, regulatory and operational circumstances of each regulated entity.

Identifying Important Business Services

An important business service is generally a service whose disruption could cause significant harm to customers, markets or the organization’s regulatory objectives.

Potential examples for financial services firms include:

• Receiving      customer funds

• Providing      customer access to funds

• Processing      domestic payments

• Processing      international payments

• Sending      remittances

• Settling      foreign exchange transactions

• Maintaining      digital wallets

• Processing      merchant settlements

• Safeguarding      customer funds

• Reporting      fraud

• Freezing      compromised accounts

• Supporting      vulnerable customers

The methodology should begin with services delivered to an identifiable external user rather than internal department names.

For example:

• “Information      Technology” is a function.

• “Enabling      customers to access their payment accounts” is a service.

A service may be important even if it is not the organization’s largest source of revenue.

Importance should be assessed using potential harm, not commercial value alone.

Determining Whether a Service Is Important

Factors may include:

• Number      of customers affected

• Customer      type

• Vulnerable      customers

• Value      and volume of transactions

• Time      sensitivity

• Availability      of alternatives

• Potential      financial loss

• Market      impact

• Regulatory      obligations

• Safeguarding      consequences

• Fraud      exposure

• Geographic      reach

• Duration      of potential disruption

• Reputational      impact

The organization should document:

• The      services considered

• The      criteria used

• The      determination reached

• The      evidence supporting the decision

• The      approving authority

Services should be reassessed when:

• New      products are launched.

• Customers      change.

• Transaction      volumes increase.

• Technology      changes.

• Activities      are outsourced.

• New      jurisdictions are entered.

• Significant      incidents occur.

• Regulatory      expectations change.

Impact Tolerances

An impact tolerance establishes the maximum level of disruption that can occur before the harm becomes unacceptable.

The FCA describes it as the maximum tolerable disruption to an important business service before intolerable harm is caused to consumers, firms or markets.

Impact tolerances are often expressed primarily through time, such as:

• Minutes

• Hours

• One      business day

• Several      business days

However, time may not be sufficient on its own.

Additional measures may include:

• Number      of affected customers

• Value      of delayed transactions

• Volume      of unprocessed payments

• Number      of unresolved fraud reports

• Size      of unreconciled customer-fund positions

• Geographic      scope

• Data      loss

• Customer      complaints

• Regulatory      consequences

An impact tolerance should reflect the point at which further disruption could create intolerable harm.

It should not simply repeat the organization’s current recovery capability.

Setting a tolerance based on what the organization can currently achieve may conceal rather than identify a vulnerability.

Impact Tolerances vs Recovery Objectives

Impact tolerances should be distinguished from traditional recovery objectives.

Recovery Time Objective

A recovery time objective identifies the target period within which a process or system should be restored.

Recovery Point Objective

A recovery point objective identifies the maximum acceptable period of data loss, commonly measured by time.

Maximum Tolerable Period of Disruption

This represents the longest period a process or activity can remain unavailable before consequences become unacceptable.

Impact Tolerance

An impact tolerance considers the maximum acceptable disruption to an important external service before intolerable harm occurs.

These measures should be aligned.

For example, the recovery time objectives for supporting systems may need to be shorter than the impact tolerance for the service so that:

• Systems      can be restored.

• Data      can be validated.

• Reconciliations      can occur.

• Staff      can resume processing.

• Backlogs      can be cleared.

Business Impact Analysis

A business impact analysis identifies the consequences of operational disruption and the resources required for recovery.

It may examine:

• Business      processes

• Products

• Services

• Customers

• Financial      impact

• Regulatory      impact

• Customer      harm

• Operational      dependencies

• Technology

• Data

• People

• Premises

• Vendors

• Recovery      requirements

• Workarounds

The analysis may establish:

• Criticality

• Maximum      tolerable downtime

• Recovery      time objective

• Recovery      point objective

• Minimum      staffing

• Minimum      technology

• Minimum      data

• Recovery      sequence

• Internal      dependencies

• External      dependencies

The business impact analysis should be based on realistic operational information rather than copied from previous plans.

OSFI expressly identifies business impact analyses and tested continuity plans as components of business continuity risk management.

End-to-End Service Mapping

Mapping identifies the resources required to deliver an important service from beginning to end.

The map may include:

• Customers

• Processes

• Employees

• Teams

• Systems

• Applications

• Data

• Facilities

• Vendors

• Banking      partners

• Payment      networks

• Communications

• Controls

• Jurisdictions

• Legal      entities

The objective is not to produce the most complicated diagram possible.

The objective is to provide enough detail to:

• Understand      dependencies

• Identify      vulnerabilities

• Design      tests

• Prioritize      remediation

• Respond      effectively during incidents

The FCA expects firms to map the resources necessary to deliver important business services and to use that mapping to support testing and resilience.

Mapping People

People-related mapping may identify:

• Required      roles

• Required      skills

• Minimum      staffing

• Key      individuals

• Geographic      concentration

• Shift      coverage

• Succession      arrangements

• Access      permissions

• Remote-working      capability

• Training      requirements

Organizations should identify excessive dependency on:

• One      employee

• One      specialist team

• One      office

• One      country

• One      vendor contact

Plans should consider widespread rather than isolated staff unavailability.

Mapping Processes

Process mapping may identify:

• Trigger      events

• Inputs

• Outputs

• Approvals

• Manual      steps

• Automated      steps

• Controls

• Exceptions

• Escalation

• Reconciliations

• Dependencies

Manual workarounds should be documented and tested.

A workaround that exists only as a conceptual possibility may not function under pressure.

Mapping Technology

Technology mapping may include:

• Core      platforms

• Applications

• Databases

• Cloud      services

• Networks

• APIs

• Authentication

• Cybersecurity      tools

• Data      feeds

• Payment      connections

• Monitoring      systems

• Backup      environments

The organization should understand both direct and indirect dependencies.

A customer-facing system may be available while an essential identity, screening, payment or communications interface is unavailable.

Mapping Data

Data mapping may identify:

• Critical      datasets

• Sources

• Owners

• Interfaces

• Storage

• Backups

• Retention

• Integrity      controls

• Recovery      requirements

• Manual      alternatives

Data availability alone is not sufficient.

The organization must also consider:

• Accuracy

• Completeness

• Integrity

• Timeliness

• Reconciliation

• Confidentiality

A corrupted dataset may be more dangerous than a temporary outage because it can create incorrect transactions or decisions without immediate detection.

Mapping Facilities

Facility dependencies may include:

• Offices

• Operations      centres

• Data      centres

• Call      centres

• Records      storage

• Secure      working areas

• Network      infrastructure

• Power

• Telecommunications

Continuity strategies may include:

• Remote      working

• Alternate      locations

• Split      teams

• Reciprocal      arrangements

• Temporary      facilities

• Mobile      equipment

The organization should assess whether alternative locations depend on the same:

• Utility      provider

• Telecommunications      network

• Transport      infrastructure

• Geographic      region

• Technology      environment

Mapping Third Parties

Third-party mapping should identify:

• Service      provider

• Service      delivered

• Systems      supported

• Data      processed

• Subcontractors

• Geographic      location

• Recovery      commitments

• Incident      contacts

• Alternative      providers

• Exit      arrangements

A vendor’s service-level agreement may not align with the organization’s impact tolerance.

For example, a vendor may commit to restore service within 24 hours while the organization’s important service can tolerate only four hours of disruption.

The gap should be identified and managed before an incident occurs.

Operational Dependencies

Operational dependencies may be:

Internal

• Technology      teams

• Treasury

• Compliance

• Customer      service

• Finance

• Operations

• Legal

• Human      resources

External

• Banks

• Cloud      providers

• Payment      processors

• Card      networks

• Telecommunications      companies

• Identity      providers

• Screening      vendors

• Liquidity      providers

• Government      services

Hidden

Hidden dependencies may arise where multiple systems or vendors rely on:

• The      same cloud provider

• The      same data centre

• The      same subcontractor

• The      same network

• The      same software library

• The      same bank

• The      same geographic region

Resilience assessments should look beyond direct contractual relationships.

Vulnerability Assessment

Once important services and dependencies have been mapped, the organization should identify vulnerabilities.

Examples include:

• Single      points of failure

• Inadequate      system capacity

• Outdated      technology

• Unsupported      software

• Weak      backup arrangements

• Incomplete      plans

• Untested      workarounds

• Key-person      dependency

• Geographic      concentration

• Vendor      concentration

• Insufficient      staffing

• Poor      data quality

• Inadequate      communications

• Excessive      recovery time

• Lack      of alternate providers

• Manual      processes that cannot scale

Vulnerabilities should be:

• Recorded

• Risk      assessed

• Prioritized

• Assigned

• Remediated

• Tracked

• Reported

Management should formally accept residual risk where immediate remediation is not practical.

Resilience by Design

Operational resilience should be considered during the design of:

• Products

• Processes

• Systems

• Vendor      arrangements

• Customer      journeys

• Organizational      structures

Resilience-by-design principles may include:

• Avoiding      single points of failure

• Building      redundancy

• Maintaining      sufficient capacity

• Separating      critical environments

• Designing      safe fallback arrangements

• Preserving      audit trails

• Supporting      manual intervention

• Maintaining      alternative communication channels

• Designing      recoverable data architectures

• Testing      before launch

It is generally more effective to design resilience into a service than to add it after a major disruption.

Business Continuity Strategies

Continuity strategies define how critical activities will be maintained or restored.

Possible strategies include:

• Remote      working

• Alternate      premises

• Cross-trained      staff

• Manual      processing

• Work      redistribution

• System      failover

• Backup      infrastructure

• Alternative      vendors

• Data      restoration

• Reduced      service levels

• Customer      prioritization

• Temporary      transaction limits

• Deferred      non-critical activity

The strategy should be:

• Practical

• Affordable

• Tested

• Documented

• Aligned      with recovery objectives

• Supported      by necessary resources

A strategy should not depend on assumptions that may be invalid during a severe event.

For example:

• All      employees may not be available.

• Vendors      may be affected simultaneously.

• Remote      access may be overloaded.

• The      primary communication channel may fail.

• Customers      may generate unusually high contact volumes.

Business Continuity Plans

A business continuity plan should provide clear and usable instructions.

It may include:

• Purpose      and scope

• Activation      criteria

• Roles      and responsibilities

• Contact      information

• Escalation      procedures

• Critical      activities

• Recovery      priorities

• Workarounds

• Required      resources

• Internal      communications

• Customer      communications

• Regulatory      notifications

• Vendor      contacts

• Recovery      procedures

• Stand-down      criteria

• Post-incident      review

Plans should be:

• Accessible      during outages

• Version      controlled

• Reviewed      regularly

• Tested

• Supported      by contact lists

• Understood      by responsible staff

Critical plans should not be stored only within systems that may be unavailable during an incident.

Crisis Management

Crisis management coordinates strategic decision-making during a major disruption.

A crisis-management structure may include:

• Crisis      leader

• Operations

• Technology

• Cybersecurity

• Compliance

• Legal

• Communications

• Customer      service

• Finance

• Human      resources

• Vendor      management

The crisis team may be responsible for:

• Assessing      severity

• Setting      priorities

• Activating      plans

• Allocating      resources

• Approving      communications

• Escalating      to the board

• Notifying      regulators

• Protecting      customers

• Monitoring      recovery

• Ending      the crisis response

Decision-making authority should be established before the crisis.

Incident Management and Operational Resilience

Incident management and operational resilience should be connected.

The incident-management process may include:

1. Detection

2. Logging

3. Classification

4. Escalation

5. Containment

6. Continuity      activation

7. Recovery

8. Communication

9. Regulatory      assessment

10. Resolution

11. Root-cause      analysis

12. Remediation

13. Lessons      learned

Incident severity should consider service impact, not merely the technical cause.

A small technical problem may create a major operational event if it affects an important customer service.

Cybersecurity and Operational Resilience

Cyber incidents may affect:

• Availability

• Confidentiality

• Integrity

• Authentication

• Customer      access

• Payment      processing

• Data      recovery

Relevant scenarios include:

• Ransomware

• Distributed      denial-of-service attacks

• Credential      compromise

• Data      destruction

• Malicious      insiders

• Cloud      compromise

• Supply-chain      attacks

• Payment-system      manipulation

Cyber recovery may require different assumptions than ordinary technology failure.

For example:

• Backups      may be compromised.

• Systems      may need forensic review before restoration.

• Credentials      may need to be replaced.

• Data      integrity may be uncertain.

• Attackers      may still have access.

• Normal      recovery environments may not be safe.

NIST’s Cybersecurity Framework supports organizations in understanding and reducing cybersecurity risk, while its contingency-planning guidance addresses recovery requirements and priorities for systems and operations.

Technology Disaster Recovery

Technology disaster recovery should align with the needs of important services.

The framework may cover:

• Recovery      tiers

• System      criticality

• Backup      frequency

• Data      replication

• Recovery      time objectives

• Recovery      point objectives

• Failover

• Restoration

• Capacity

• Cyber      recovery

• Testing

• Documentation

Technical recovery testing should verify more than whether a backup can be restored.

It should also confirm:

• Applications      function correctly.

• Interfaces      reconnect.

• Data      is complete.

• Users      can access the system.

• Security      controls operate.

• Reconciliations      can occur.

• Transaction      backlogs can be processed.

Data Backup and Recovery

Backup arrangements should consider:

• Frequency

• Location

• Segregation

• Encryption

• Access

• Immutability

• Integrity

• Retention

• Restoration      time

• Testing

Organizations should maintain confidence that backups are:

• Available

• Complete

• Uncorrupted

• Protected      from the original incident

• Capable      of being restored within required timeframes

Backup success reports do not replace restoration testing.

Third-Party Operational Resilience

Outsourcing does not transfer regulatory accountability.

Organizations should assess whether critical third parties can support the resilience of important services.

Due diligence may cover:

• Business      continuity

• Disaster      recovery

• Cybersecurity

• Financial      stability

• Staffing

• Geographic      concentration

• Subcontractors

• Incident      history

• Recovery      capabilities

• Testing

• Communications

• Exit      planning

Contracts may address:

• Recovery      commitments

• Incident      notification

• Participation      in testing

• Access      to information

• Audit      rights

• Regulatory      access

• Data      recovery

• Subcontracting

• Exit      assistance

The organization should not rely solely on a vendor’s general continuity certification.

It should assess whether the vendor’s arrangements support the organization’s specific service and impact tolerance.

Third-Party Failure Scenarios

Testing should consider scenarios such as:

• Cloud-provider      outage

• Bank-account      restriction

• Payment-processor      failure

• Identity-provider      outage

• Telecommunications      disruption

• Sanctions-screening      failure

• Vendor      cyberattack

• Vendor      insolvency

• Vendor      data corruption

• Simultaneous      vendor and internal failure

The Bank of England’s 2026 Cyber and Operational Resilience Stress Test included a cloud-service-provider and third-party disruption scenario, illustrating continued regulatory focus on concentrated technology dependencies.

Concentration Risk

Concentration risk may arise where:

• Several      services use the same vendor.

• Several      vendors use the same subcontractor.

• Operations      depend on one bank.

• Data      is hosted in one geographic region.

• Critical      staff work in one location.

• Multiple      systems rely on one identity provider.

• One      telecommunications provider supports all sites.

Concentration should be assessed at the enterprise level.

Reviewing each contract independently may fail to reveal the organization’s aggregate dependency.

Exit and Substitution Planning

Exit planning should consider how the organization could replace or internalize a critical service.

The plan may address:

• Trigger      events

• Decision      authority

• Alternative      providers

• Data      extraction

• Data      migration

• Knowledge      transfer

• Customer      communication

• Regulatory      approval

• Transition      risks

• Required      time

• Cost

• Contract      termination

• Secure      data deletion

Exit plans should distinguish between:

• Planned      exit

• Emergency      exit

• Vendor      failure

• Regulatory-mandated      exit

An exit plan that requires several months may not address a sudden vendor failure.

Scenario Testing

Scenario testing assesses whether important services can remain within their impact tolerances during severe but plausible disruption.

The FCA expects firms to maintain testing plans demonstrating that they can remain within impact tolerances through scenarios that vary in nature, severity and duration.

Possible scenarios include:

• Ransomware

• Cloud      outage

• Payment-network      failure

• Bank      failure

• Loss      of customer data

• Staff      unavailability

• Loss      of premises

• Telecommunications      failure

• Vendor      insolvency

• Fraud      attack

• Extreme      transaction volumes

• Simultaneous      failures

• Prolonged      utility outage

• Data      corruption

Scenarios should be:

• Severe

• Plausible

• Relevant

• Challenging

• Connected      to identified vulnerabilities

• Designed      around important services

Testing only convenient or easily managed scenarios may create false confidence.

Types of Exercises and Tests

Tabletop Exercise

Participants discuss how they would respond to a scenario.

This helps test:

• Roles

• Decisions

• Escalation

• Communications

• Assumptions

Simulation

The organization recreates elements of a disruption without affecting production services.

This helps test:

• Coordination

• Response

• Workarounds

• Decision-making

Technical Recovery Test

Systems or data are restored in a controlled environment.

This helps test:

• Backups

• Recovery      procedures

• Capacity

• Data      integrity

Failover Test

Operations are moved to an alternative environment.

This helps test:

• Redundancy

• Connectivity

• User      access

• Performance

End-to-End Service Test

The organization tests the complete service across people, process, technology, data and third parties.

This is particularly important for operational resilience because isolated component tests may not demonstrate that the customer service can continue.

Testing Impact Tolerances

Testing should answer:

• When      does disruption begin?

• How      quickly is it detected?

• When      is the plan activated?

• Can      the workaround operate?

• How      many customers are affected?

• Does      the service remain within tolerance?

• Can      backlogs be cleared?

• Are      customers informed?

• Are      vulnerable customers supported?

• Are      regulators notified?

• What      fails first?

• Which      assumptions prove incorrect?

Testing results should identify:

• Performance      achieved

• Gaps

• Lessons

• Required      remediation

• Owners

• Deadlines

• Retesting      needs

A failed test is not necessarily evidence of poor governance.

Failing to address a known weakness is more serious.

Test Governance

Testing governance should define:

• Annual      test plan

• Risk-based      frequency

• Scenario      selection

• Participants

• Observers

• Success      criteria

• Evidence

• Reporting

• Issue      management

• Retesting

• Board      oversight

Higher-risk services should generally receive more extensive and frequent testing.

Tests should also be triggered by:

• Material      system changes

• New      vendors

• New      products

• Significant      incidents

• Major      organizational change

• Changes      in threat conditions

Manual Workarounds

Manual workarounds can provide temporary resilience when technology is unavailable.

Examples include:

• Manual      payment instructions

• Spreadsheet-based      tracking

• Telephone      verification

• Offline      customer records

• Manual      reconciliations

• Alternative      communication channels

Workarounds should be assessed for:

• Capacity

• Accuracy

• Fraud      risk

• Privacy

• Security

• Record      keeping

• Segregation      of duties

• Sustainability

• Customer      impact

A process normally handling thousands of transactions may not be capable of operating manually at full volume.

The organization may need to prioritize:

• Vulnerable      customers

• High-value      transactions

• Time-critical      payments

• Safeguarding      activities

• Regulatory      obligations

Communications During Disruption

Communication is a critical resilience control.

Stakeholders may include:

• Customers

• Employees

• Regulators

• Banking      partners

• Vendors

• Payment      schemes

• Law      enforcement

• Investors

• Media

Communications procedures should define:

• Who      communicates

• Who      approves

• Which      channels are used

• How      often updates are issued

• What      information can be disclosed

• How      vulnerable customers are supported

• How      alternative services are explained

Messages should be:

• Accurate

• Timely

• Clear

• Consistent

• Honest      about uncertainty

• Updated      as circumstances change

The organization should maintain alternative communication channels in case normal systems are unavailable.

Customer Communication

Customers may need information regarding:

• Service      availability

• Delayed      payments

• Access      to funds

• Alternative      channels

• Fraud      precautions

• Expected      recovery

• Complaint      routes

• Emergency      support

Communication should not promise a recovery time that has not been validated.

Where appropriate, customers should be told:

• What      has happened

• Which      services are affected

• What      action they should take

• What      the organization is doing

• When      the next update will occur

Vulnerable Customers

Operational disruption may have disproportionate effects on vulnerable customers.

The framework should consider customers who may:

• Depend      on immediate access to funds

• Have      limited alternative payment methods

• Need      language support

• Have      disabilities

• Be      experiencing financial distress

• Be      subject to fraud or domestic abuse

• Have      limited digital access

Continuity strategies may include:

• Priority      support

• Alternative      authentication

• Accessible      communications

• Emergency      payment procedures

• Human      assistance

• Extended      service channels

Impact tolerances should consider the severity of harm, not only the number of customers affected.

Regulatory Reporting and Notifications

Operational incidents may require reporting to:

• Financial      services regulators

• Central      banks

• Privacy      regulators

• Financial      intelligence units

• Payment      schemes

• Licensing      authorities

• Other      government bodies

The incident process should include:

• Notification      criteria

• Materiality      assessment

• Reporting      deadlines

• Responsible      owner

• Approval

• Initial      report

• Interim      updates

• Final      report

• Evidence      retention

In the United Kingdom, operational-incident and material third-party reporting requirements continued to develop in 2026, including the PRA’s publication of its final reporting policy.

Organizations operating across jurisdictions should avoid assuming that one regulator’s reporting threshold or deadline applies to all authorities.

Financial Resilience During Disruption

Operational events may create:

• Lost      revenue

• Increased      expenses

• Customer      remediation

• Fraud      losses

• Liquidity      needs

• Vendor      costs

• Legal      costs

• Regulatory      penalties

• Insurance      claims

Continuity planning should consider:

• Emergency      funding

• Liquidity

• Insurance

• Spending      authority

• Vendor      payments

• Payroll

• Customer      reimbursement

• Financial      forecasting

A prolonged disruption may become a viability or wind-down issue.

Operational resilience should therefore connect with:

• Capital      planning

• Liquidity      planning

• Safeguarding

• Recovery      planning

• Wind-down      planning

Safeguarding and Customer Funds

Firms holding customer money should maintain continuity for:

• Segregation

• Account      access

• Reconciliations

• Shortfall      identification

• Shortfall      funding

• Transaction      records

• Customer      entitlement records

• Banking      communication

A technology incident should not prevent the organization from knowing:

• How      much customer money it holds

• Where      the funds are held

• Whether      a shortfall exists

• Which      customers are entitled to the funds

Safeguarding continuity should be tested as part of end-to-end resilience.

Fraud Risk During Disruption

Fraudsters may exploit operational disruption through:

• Impersonation

• Phishing

• Account      takeover

• False      payment instructions

• Social      engineering

• Customer-support      manipulation

• Control      bypass

• Manual-workaround      abuse

Continuity plans should preserve critical fraud controls.

Where normal controls are unavailable, alternative arrangements may be necessary for:

• Authentication

• Payment      approval

• Transaction      limits

• Customer      contact

• Monitoring

• Escalation

Emergency procedures should not create uncontrolled access to customer funds.

Financial Crime Controls During Disruption

Organizations should determine how they will continue:

• Sanctions      screening

• Customer      due diligence

• Transaction      monitoring

• Suspicious-activity      escalation

• Regulatory      reporting

• Record      keeping

A disruption may not justify processing transactions without required financial crime controls.

The plan may provide for:

• Alternative      screening

• Manual      review

• Reduced      transaction limits

• Temporary      service restrictions

• Deferred      processing

• Additional      approvals

Decisions should be documented and proportionate to the risk.

Remote Working Resilience

Remote working may support continuity but can create additional risks.

These may include:

• Network      capacity

• Device      availability

• Cybersecurity

• Privacy

• Home      connectivity

• Employee      wellbeing

• Supervision

• Access      controls

• Secure      communications

• Fraud

Organizations should determine whether critical teams can operate remotely at the same time.

Testing should include realistic assumptions about:

• Internet      availability

• Equipment

• authentication

• telephone      capacity

• access      to records

• home      working environments

People Resilience

People resilience includes:

• Succession      planning

• Cross-training

• Role      coverage

• Emergency      contacts

• Staff      welfare

• Travel      arrangements

• Leadership      continuity

• Contractor      access

• Knowledge      management

Plans should avoid dependency on one individual’s knowledge or authority.

Critical decisions should have:

• Primary      authority

• Alternate      authority

• Documented      thresholds

• Clear      escalation

Change Management and Resilience

Technology, product and organizational changes can introduce resilience weaknesses.

Change assessments should consider:

• Important      services affected

• Recovery      arrangements

• Capacity

• Data      migration

• Vendor      dependency

• Updated      plans

• Testing

• Customer      communication

• Rollback

Resilience should be assessed before implementation.

A significant change may require:

• Updated      mapping

• Revised      impact tolerances

• New      scenario testing

• Updated      continuity plans

• Staff      training

Mergers, Acquisitions and Growth

Business expansion can create operational complexity.

Potential concerns include:

• Duplicate      systems

• Inconsistent      plans

• Unclear      ownership

• Multiple      vendors

• Data      migration

• Geographic      concentration

• Increased      transaction volume

• New      regulatory requirements

Organizations should assess whether resilience arrangements remain appropriate as the business grows.

A plan designed for a small operation may not remain effective after significant customer or transaction growth.

Plan Maintenance

Continuity plans should be reviewed:

• At      least periodically

• Following      testing

• Following      incidents

• After      material changes

• When      owners change

• When      vendors change

• When      systems change

• When      contact details change

• When      regulatory expectations change

Plan maintenance should be assigned to named owners.

A plan may appear complete while containing:

• Former      employees

• Expired      telephone numbers

• Retired      systems

• Old      vendors

• Incorrect      escalation routes

• Unavailable      facilities

Regular validation is essential.

Lessons Learned

Post-incident and post-test reviews should assess:

• What      happened

• What      worked

• What      failed

• Which      assumptions were incorrect

• Whether      escalation was timely

• Whether      communications were effective

• Whether      customers were harmed

• Whether      impact tolerances were exceeded

• Whether      vendors performed

• Which      actions are required

Lessons should result in:

• Updated      plans

• Updated      mapping

• Control      improvements

• Training

• Vendor      remediation

• Technology      investment

• Revised      testing

• Management      reporting

Lessons should be tracked until implementation rather than recorded and forgotten.

Key Risk Indicators

Operational resilience indicators may include:

• Service      availability

• Number      of material incidents

• Duration      of incidents

• Impact-tolerance      breaches

• Recovery-time      performance

• Failed      backups

• Failed      recovery tests

• Open      continuity findings

• Overdue      plans

• Unresolved      single points of failure

• Critical-vendor      incidents

• Capacity      utilization

• Customer      complaints

• Manual-workaround      capacity

• Staff      concentration

• Unplanned      system downtime

Indicators should have:

• Definitions

• Data      owners

• Thresholds

• Escalation      requirements

• Reporting      frequency

Metrics should focus on service outcomes as well as technology performance.

Management Information

Management information may include:

• Important-service      status

• Impact      tolerances

• Mapping      completion

• Principal      vulnerabilities

• Remediation      progress

• Testing      results

• Incidents

• Vendor      performance

• Plan      status

• Regulatory      developments

• Risk      acceptance

• Resource      requirements

Reporting should distinguish between:

• Plans      completed

• Plans      tested

• Tests      passed

• Vulnerabilities      remediated

• Services      demonstrably able to remain within tolerance

Document completion alone does not demonstrate resilience.

Board Reporting

Board reporting should support meaningful challenge.

It may address:

• Most      important services

• Maximum      tolerable disruption

• Ability      to remain within tolerance

• Significant      vulnerabilities

• Material      incidents

• Third-party      concentration

• Testing      outcomes

• Overdue      remediation

• Strategic      investment

• Regulatory      findings

Boards should understand where the organization is relying on:

• Temporary      workarounds

• Unvalidated      assumptions

• Unremediated      weaknesses

• Vendor      commitments

• Formal      risk acceptance

Compliance Monitoring and Testing

Compliance monitoring may assess whether:

• Important      services are identified.

• Impact      tolerances are approved.

• Mapping      is complete.

• Plans      are current.

• Tests      occur as scheduled.

• Findings      are remediated.

• Vendor      continuity is reviewed.

• Regulatory      notifications are made.

• Management      information is accurate.

• Required      records are retained.

Monitoring should review operating effectiveness rather than simply policy existence.

For example, testing may confirm whether:

• Contact      numbers work.

• Alternate      users can access systems.

• Manual      workarounds can handle expected volume.

• Backup      data can be restored.

• Vendors      respond within contracted timelines.

• Communications      can be issued through alternate channels.

Independent Review

Independent assurance can evaluate the design and operation of the resilience framework.

The review may cover:

• Governance

• Policies

• Important      services

• Impact      tolerances

• Business      impact analysis

• Mapping

• Continuity      strategies

• Plans

• Crisis      management

• Technology      recovery

• Third-party      resilience

• Scenario      testing

• Communications

• Reporting

• Issue      management

• Training

Independent review should consider whether the organization can demonstrate resilience through evidence rather than documentation alone.

Business Continuity and Operational Resilience in Canada

Canadian financial institutions may be subject to operational-risk, technology-risk and resilience expectations depending on their regulatory status.

OSFI Guideline E-21 establishes expectations for federally regulated financial institutions involving:

• Operational      risk management

• Operational      resilience

• Business      continuity risk management

• Crisis      management

• Change      management

• Data      risk management

The guideline expects business continuity to strengthen operational resilience and evolve toward critical operations considered from end to end.

Other Canadian organizations may also need to consider requirements arising through:

• Bank      of Canada supervision

• The      Retail Payment Activities Act

• Provincial      regulation

• Privacy      law

• Contractual      commitments

• Payment-network      rules

• Banking-partner      requirements

Even where OSFI guidance does not apply directly, its principles may provide useful benchmarks for mature resilience governance.

Business Continuity and Operational Resilience in the United Kingdom

The UK operational resilience framework places significant emphasis on:

• Important      business services

• Impact      tolerances

• Mapping

• Scenario      testing

• Vulnerability      remediation

• Communication

• Governance

Firms within scope are expected to ensure they can remain within the impact tolerance for each important business service during severe but plausible disruption.

The transition period associated with the original FCA framework ended on March 31, 2025. The FCA’s subsequent observations have emphasized the continuing need for sophisticated testing, dynamic mapping and effective remediation rather than treating the framework as a one-time implementation project.

UK firms should also coordinate operational resilience with:

• Consumer      Duty

• Outsourcing

• Third-party      risk

• Technology      risk

• Cybersecurity

• Regulatory      reporting

• Senior-management      accountability

Business Continuity and Operational Resilience in the United States

The United States applies continuity and resilience expectations through multiple regulatory, supervisory and sector-specific frameworks.

Financial institutions may need to consider requirements and guidance involving:

• Business      continuity

• Information      security

• Disaster      recovery

• Cybersecurity

• Third-party      risk

• Incident      notification

• Payment-system      requirements

• Consumer      protection

• Prudential      supervision

NIST guidance can support structured contingency planning, cybersecurity risk management and recovery, although the organization should separately identify all binding requirements applicable to its regulated activities.

Organizations operating across multiple states or regulated sectors should maintain a jurisdiction-specific inventory of continuity, testing and notification obligations.