---
title: [CM] [BDCB] [E3] [CRA] [P1-3] List of Crisis Scenarios [Technology]
description: [CM] [BDCB] [E3] [CRA] [P1-3] List of Crisis Scenarios [Technology]
image: https://blog.bcm-institute.org/hubfs/BDCB%20Graphic%20Folder/BDCB%20CM%20Graphic%20Folder/BDCB%20CM%20E3%20Morepost/%5BCM%5D%20%5BBDCB%5D%20%5BE3%5D%20%5BCRA%5D%20%5BP1-3%5D%20List%20of%20Crisis%20Scenarios%20%5BTechnology%5D.jpg
---

.

[![BCMIWhiteLogo.png](https://blog.bcm-institute.org/hs-fs/hubfs/Blog%20Testing/BCMIWhiteLogo.png?width=556&name=BCMIWhiteLogo.png "BCMIWhiteLogo.png")](http://www.bcm-institute.org/)

- [Home](https://www.bcm-institute.org/)
- [About Us](https://www.bcm-institute.org/about-us-3/) 
    - [A President’s Perspective](https://www.bcm-institute.org/about-us/a-presidents-perspective/)
    - [Our History](https://www.bcm-institute.org/about-us/our-history/)
    - [Our Advisory Council](https://www.bcm-institute.org/about-us/our-advisory-council/)
    - [Customers’ Testimonials](https://www.bcm-institute.org/about-us/customers-testimonials/)
    - [Credential Verification](https://www.bcm-institute.org/about-us/credential-verification/)
- [Courses](https://blog.bcm-institute.org/blog/course-fees-for-blended-learning-courses-master-catalog) 
    - [ISO 22301 Business Continuity Management System Audit](https://blog.bcm-institute.org/audit/business-continuity-management-audit-courses)
    - [ISO 22301 Business Continuity Management](https://blog.bcm-institute.org/bcm/business-continuity-management-courses)
    - [Crisis Communication](https://blog.bcm-institute.org/crisis-communication/crisis-communication-courses)
    - [Crisis Management](https://blog.bcm-institute.org/en/crisis-management/courses)
    - [IT Disaster Recovery](https://blog.bcm-institute.org/it-disaster-recovery/courses)
    - [Operational Resilience](https://blog.bcm-institute.org/operational-resilience/courses)
    - [Operational Resilience Audit](https://blog.bcm-institute.org/operational-resilience-audit/courses)
- [Certification](https://blog.bcm-institute.org/certification/types-of-certifications-offered) 
    - [ISO 22301 BCMS Audit Certification](https://blog.bcm-institute.org/certification/business-continuity-management-audit-certification)
    - [ISO22301 Business Continuity Management Certification](https://blog.bcm-institute.org/bcm/business-continuity-management-certification)
    - [Crisis Communication Certification](https://blog.bcm-institute.org/crisis-communication/crisis-communication-certification)
    - [Crisis Management Certification](https://blog.bcm-institute.org/en/crisis-management/crisis-management-certification)
    - [IT Disaster Recovery Planning Certification](https://blog.bcm-institute.org/it-disaster-recovery/it-disaster-recovery-certification)
    - [Operational Resilience Certification](https://blog.bcm-institute.org/operational-resilience/operational-resilience-certification)
    - [Operational Resilience Audit Certification](https://blog.bcm-institute.org/operational-resilience-audit)
- [Seminars](https://blog.bcm-institute.org/meet-the-expert/mte-webinar-mainpage)
- [Store](https://www.bcm-institute.org/store-2/)
- [Contact Us](http://www.bcm-institute.org/about-us/contact-us/)

- <https://www.facebook.com/BCMInstitute/>
- <https://www.linkedin.com/company/business-continuity-management-institute-bcm-institute>

##### Crisis Management in Action: A Practical Implementation Guide for BDCB

![CM Ai Gen\_with Cert Logo\_v3-11](https://blog.bcm-institute.org/hs-fs/hubfs/BB%20CM%20%5BAi%20Gen%20Blog%20Photo%5D/BB%20CM%20v3%20Jun%202025/CM%20Ai%20Gen_with%20Cert%20Logo_v3-11.jpg?width=2000&height=1333&name=CM%20Ai%20Gen_with%20Cert%20Logo_v3-11.jpg "CM Ai Gen_with Cert Logo_v3-11")

# \[CM\] \[BDCB\] \[E3\] \[CRA\] \[P1-3\] List of Crisis Scenarios \[Technology\]

[![\[CM\] \[BDCB\] \[Full Banner\] Crisis Management in Action\_ A Practical Implementation Guide for BDCB](https://no-cache.hubspot.com/cta/default/3893111/399bc296-6bd2-4c03-8819-8bfe517a3e07.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/399bc296-6bd2-4c03-8819-8bfe517a3e07)

Technology is fundamental to the ability of the **Brunei Darussalam Central Bank (BDCB)** to perform its central-banking, supervisory, financial-infrastructure, and corporate responsibilities.

A significant technology disruption can therefore develop beyond an ordinary IT incident and become an organisational or financial-sector crisis when it affects critical services, information integrity, financial institutions, payment and settlement activities, public confidence, or financial stability.

This is particularly relevant because BDCB operates Brunei Darussalam's **National Payment and Settlement Systems (NPSS)**, comprising the **Real Time Gross Settlement System (RTGS), Automated Clearing House (ACH), and Central Securities Depository (CSD)**.

BDCB describes safe, reliable, and efficient financial-market infrastructures as important to financial stability and economic growth.

The purpose of **CRA Part 1-3** is therefore to expand the technological category within BDCB's Crisis Risk Assessment by identifying a more detailed catalogue of credible technology threats and crisis scenarios.

[![\[Banner\] \[Title\] \[CM\] \[E3\] Part 1-3\_ List of Crisis Scenarios \[Technology\]](https://no-cache.hubspot.com/cta/default/3893111/89fff399-1f2d-4c97-ab4e-5af735da307d.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/89fff399-1f2d-4c97-ab4e-5af735da307d)

[Moh Heng Goh](https://blog.bcm-institute.org/en/ebook-cm/author/moh-heng-goh) Oct 7, 2026

###### Crisis Management Certified Planner-Specialist-Expert

##### [![\[CM\] \[BDCB\] Legal Disclaimer Banner](https://no-cache.hubspot.com/cta/default/3893111/062c8304-1699-4f7b-a38d-f128d9815304.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/062c8304-1699-4f7b-a38d-f128d9815304)

### [![\[Banner\] \[Title\] \[CM\] \[E3\] Part 1-3\_ List of Crisis Scenarios \[Technology\]](https://no-cache.hubspot.com/cta/default/3893111/89fff399-1f2d-4c97-ab4e-5af735da307d.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/89fff399-1f2d-4c97-ab4e-5af735da307d)

### List of Technology Threats for the Brunei Darussalam Central Bank

#### Introduction

[![\[CM\] \[BDCB\] \[E3\] \[CRA\] \[P1-3\] List of Crisis Scenarios \[Technology\] ](https://no-cache.hubspot.com/cta/default/3893111/883a9c65-15e5-408d-a406-3835732e8f16.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/883a9c65-15e5-408d-a406-3835732e8f16)Technology is fundamental to the Brunei Darussalam Central Bank's (BDCB) ability to perform its central-banking, supervisory, financial-infrastructure, and corporate responsibilities.

A significant technology disruption can therefore escalate beyond an ordinary IT incident into an organisational or financial-sector crisis when it affects critical services, information integrity, financial institutions, payment and settlement activities, public confidence, or financial stability.

This is particularly relevant because BDCB operates Brunei Darussalam's **National Payment and Settlement Systems (NPSS)**, comprising the **Real Time Gross Settlement System (RTGS), Automated Clearing House (ACH), and Central Securities Depository (CSD)**.

BDCB describes safe, reliable, and efficient financial-market infrastructures as important to financial stability and economic growth.

The purpose of **CRA Part 1-3** is therefore to expand the technological category within BDCB's Crisis Risk Assessment by identifying a more detailed catalogue of credible technology threats and crisis scenarios.

The catalogue should support subsequent risk assessment, treatment and control, scenario development, Crisis Management planning, exercising, and continual improvement.

The entries below are **illustrative planning scenarios** developed for the eBook. They should not be interpreted as statements that these incidents have occurred at BDCB or that BDCB currently has particular technological weaknesses.

##### **Interpretation of the Table**

**Country Level** indicates whether the scenario could reasonably affect Brunei's wider financial sector, financial infrastructure, businesses, consumers, or national environment.

**Organisation Level** indicates whether the scenario could directly or indirectly affect BDCB's people, processes, technology, information, facilities, responsibilities, or ability to deliver critical activities.

A designation of **Yes** means that the threat should be considered in the Crisis Risk Assessment; it does not indicate that the threat has occurred.

#### **Detailed List of Technological Threats**

 

| Type of Threats / Crisis Scenario (Technological) | Description of Threats | Country Level | Organisation Level |
| --- | --- | --- | --- |
| Hardware Failure | Failure of servers, storage, network appliances, security devices, or other critical computing equipment could disrupt applications and supporting services. A failure involving a critical component without effective redundancy could escalate into a prolonged service disruption. | Yes | Yes |
| Server Failure | Failure of physical or virtual servers supporting critical BDCB applications could make systems unavailable, degrade processing capability, or interrupt services until failover or recovery is completed. | Potential | Yes |
| Storage Infrastructure Failure | Failure or corruption affecting storage arrays, storage networks, or associated infrastructure could make applications and information unavailable and potentially create data-integrity concerns. | Potential | Yes |
| Software/Application Failure | Defects, software crashes, configuration errors, or application-component failures could prevent users or automated processes from completing critical activities. | Yes | Yes |
| Operating-System Failure | Failure, corruption, incompatibility, or defective updates to operating systems could affect servers, endpoints, or critical technology platforms and cause widespread service interruption. | Potential | Yes |
| Database Failure | Database unavailability, corruption, performance degradation, or transactional inconsistency could prevent critical applications from processing reliable information. | Yes | Yes |
| Database Corruption | Logical or physical corruption could make records inaccurate or unusable. The crisis becomes more serious when BDCB cannot establish which records or transactions can be trusted. | Yes | Yes |
| Network Failure | Failure of core switches, routers, firewalls, network links, or associated infrastructure could prevent users, systems, and external parties from communicating with BDCB technology services. | Yes | Yes |
| Internal Network Segmentation Failure | Failure or misconfiguration of network segmentation could disrupt legitimate connectivity or allow faults or cyber incidents to spread between environments that should remain isolated. | Potential | Yes |
| Internet Connectivity Failure | Loss or serious degradation of internet connectivity could affect externally dependent applications, communication channels, remote access, cloud services, and interactions with external stakeholders. | Potential | Yes |
| Telecommunications Failure | Failure of telecommunications services could affect voice, data, and crisis communications and impair connectivity with financial institutions, service providers, and other stakeholders. | Yes | Yes |
| Multiple Telecommunications Provider Failure | Simultaneous failure of primary and alternate communications paths could defeat normal redundancy arrangements and create a wider connectivity crisis. | Yes | Yes |
| Data Centre Failure | Fire, utility loss, equipment failure, environmental failure, physical damage, or another event could render a primary data centre partly or wholly unavailable. | Yes | Yes |
| Secondary/Recovery Site Failure | A recovery site may be unavailable, inadequately configured, or unable to assume the required workload when needed, extending the duration of a primary-site outage. | Potential | Yes |
| Simultaneous Primary and Recovery Site Disruption | A common-cause event, shared dependency, or correlated failure could affect both primary and recovery environments, significantly reducing BDCB's recovery options. | Yes | Yes |
| Disaster Recovery Failover Failure | Systems may fail to switch successfully to recovery infrastructure because of configuration problems, dependency failures, replication issues, capacity limitations, or procedural weaknesses. | Yes | Yes |
| Disaster Recovery Failback Failure | After services have been restored at an alternate environment, problems returning operations safely to the normal production environment could cause renewed disruption or data inconsistencies. | Potential | Yes |
| Backup Failure | Backups may be incomplete, corrupted, unavailable, outdated, or otherwise unsuitable for restoration, reducing BDCB's ability to recover systems and information following a major disruption. | Potential | Yes |
| Backup Restoration Failure | Backups may exist, but restoration may fail because of technical incompatibility, corruption, missing dependencies, encryption-key problems, or inadequate recovery procedures. | Potential | Yes |
| Data Replication Failure | Failure or delay in replicating information between production and recovery environments could create unacceptable data loss or inconsistencies during failover. | Yes | Yes |
| Data Corruption/Loss of Data Integrity | Technology faults, software defects, processing errors, or other failures could alter or corrupt critical information. This may be more serious than simple unavailability because BDCB may be unable to trust the affected information. | Yes | Yes |
| Loss of Transaction Integrity | Transactions may be duplicated, omitted, altered, processed out of sequence, or recorded incorrectly, potentially affecting financial institutions and settlement or supervisory processes. | Yes | Yes |
| Data Loss | Hardware, software, operational, or recovery failures could result in permanent or temporary loss of important data, records, or transaction information. | Yes | Yes |
| Application Interface/API Failure | Failure of interfaces or APIs connecting internal systems, financial institutions, or third-party services could interrupt end-to-end processing even where individual systems remain operational. | Yes | Yes |
| Middleware/Integration Platform Failure | Failure of middleware, message brokers, or enterprise integration services could disrupt multiple applications simultaneously because otherwise functioning systems can no longer exchange information. | Yes | Yes |
| Message Queue Failure | Failure or backlog within the message-processing infrastructure could delay, duplicate, or lose system messages and transactions and create reconciliation difficulties. | Yes | Yes |
| Authentication Service Failure | Failure of the authentication infrastructure could prevent authorised employees, administrators, or external users from accessing critical systems. | Potential | Yes |
| Identity and Access Management Failure | Failure or corruption of identity services, access-control platforms, or directories could cause widespread inability to access systems or inappropriate access permissions. | Potential | Yes |
| Privileged Access Management Failure | Failure of privileged-access infrastructure could prevent administrators from recovering critical systems or create control weaknesses over sensitive administrative access. | Potential | Yes |
| Digital Certificate Failure or Expiry | Expired, revoked, or incorrectly configured certificates could disrupt secure connections, applications, interfaces, websites, or machine-to-machine communications. | Potential | Yes |
| Encryption/Key Management Failure | Loss, corruption, or unavailability of encryption keys or key-management services could make important information or systems inaccessible and disrupt secure transactions. | Yes | Yes |
| Domain Name System Failure | DNS disruption or configuration failure could make otherwise operational applications, websites, and network services inaccessible. | Potential | Yes |
| Time Synchronisation Failure | Failure of time-synchronisation services could create incorrect timestamps, transaction-sequencing problems, security-monitoring difficulties, and reconciliation issues. | Potential | Yes |
| Email and Collaboration Platform Failure | Loss of email, messaging, video conferencing, or collaboration tools could significantly impair internal coordination and external stakeholder communication, particularly during another concurrent crisis. | Potential | Yes |
| Remote Access Failure | Failure of VPN, virtual desktop, authentication, or other remote-access services could prevent employees from working remotely when the premises are inaccessible. | Potential | Yes |
| End-User Computing Failure | Widespread workstation, laptop, operating-system or endpoint-management failure could prevent a significant proportion of employees from performing their responsibilities. | Potential | Yes |
| Virtualisation Platform Failure | Failure of a shared virtualisation environment could simultaneously affect multiple servers and applications hosted on the platform. | Potential | Yes |
| Container/Orchestration Platform Failure | Where containerised applications are used, failure of the orchestration or shared platform could affect multiple application services simultaneously. | Potential | Yes |
| Cloud Service Outage | Failure of a critical cloud or hosted service could make externally hosted applications, data, or infrastructure unavailable and may affect multiple organisations simultaneously. | Yes | Yes |
| Software-as-a-Service Failure | Prolonged failure of a critical SaaS platform could prevent BDCB from performing functions dependent on the externally operated application. | Potential | Yes |
| Critical Managed-Service Provider Technology Failure | A technology failure at an outsourced or managed-service provider could disrupt BDCB services even though BDCB's own infrastructure remains operational. | Yes | Yes |
| Common Technology Provider Failure | Failure of a technology provider used by BDCB and multiple financial institutions could create simultaneous disruption across the financial ecosystem and increase systemic consequences. | Yes | Yes |
| Technology Supply-Chain Failure | Failure in hardware, software, telecommunications or technology-support supply chains could prevent timely maintenance, replacement, or recovery of critical infrastructure. | Yes | Yes |
| Software Vendor Support Failure | Loss of critical vendor expertise, delayed technical support, or withdrawal of product support could impede recovery from an application or infrastructure problem. | Potential | Yes |
| End-of-Life Technology Failure | Unsupported or obsolete hardware and software may have increased failure risk, limited vendor support, compatibility problems, or extended recovery times. | Potential | Yes |
| Failed Technology Change | A configuration change, patch, upgrade, migration, or release could introduce errors that cause system unavailability, degraded performance, or data-integrity problems. | Yes | Yes |
| Failed Software Deployment | Defective application releases or deployment processes could affect critical functions and potentially propagate across multiple environments. | Potential | Yes |
| Failed Infrastructure Upgrade | Network, server, storage, or platform upgrades could introduce incompatibility or configuration errors, resulting in widespread disruption. | Potential | Yes |
| Failed Data Migration | Migration between systems or platforms could result in missing, duplicated, corrupted, or incorrectly transformed records. | Yes | Yes |
| Failed System Migration | Migration to new technology could result in unexpected dependencies, performance problems, or loss of functionality, potentially requiring rollback or prolonged contingency arrangements. | Potential | Yes |
| Rollback Failure | A failed change may be compounded if systems cannot reliably return to the previous stable configuration. | Potential | Yes |
| Configuration Error | Incorrect configuration of servers, networks, applications, security devices, or cloud services could cause service failure or expose systems to additional risks. | Potential | Yes |
| Automation Failure | Failure of automated processing, scheduling, workflow, or robotic processes could interrupt high-volume or time-sensitive activities and create unnoticed processing backlogs. | Potential | Yes |
| Batch Processing Failure | Failure of scheduled processing could delay critical calculations, reports, reconciliations, settlement-related activities, or downstream business processes. | Potential | Yes |
| Capacity Exhaustion | Systems may become unavailable or severely degraded when processing, memory, storage, network, or database capacity is exhausted. | Yes | Yes |
| Performance Degradation | Severe latency or reduced system performance may make a service practically unusable even though it has not technically failed. | Yes | Yes |
| Unexpected Transaction-Volume Surge | An abnormal increase in transactions or user activity could exceed system capacity and affect processing or settlement performance. | Yes | Yes |
| Technology Monitoring Failure | Failure of monitoring or alerting platforms could prevent BDCB from detecting system deterioration promptly, allowing an initially manageable fault to escalate. | Potential | Yes |
| Logging Failure | Loss or corruption of system logs could impair troubleshooting, forensic investigation, reconciliation, and determination of what occurred during a technology incident. | Potential | Yes |
| IT Service Management Tool Failure | Failure of service-management, incident-ticketing, configuration, or asset-management platforms could hinder coordination and tracking during a major technology disruption. | Potential | Yes |
| RTGS System Disruption | Unavailability or severe degradation of RTGS could delay high-value and urgent interbank settlement. Because participants settle using funds held in their settlement accounts at BDCB, prolonged disruption could have wider liquidity and financial system consequences. | Yes | Yes |
| RTGS Transaction Integrity Failure | A technology problem affecting the accuracy, completeness, or sequencing of RTGS transactions could create uncertainty over settlement finality and require extensive verification before normal processing can safely resume. | Yes | Yes |
| RTGS Participant Connectivity Failure | Technology or network failure could prevent one or multiple financial institutions from connecting to RTGS, even while the central platform remains available. | Yes | Yes |
| ACH System Disruption | An ACH failure could disrupt bulk payment clearing. BDCB states that obligations arising from ACH are ultimately submitted to RTGS for settlement, creating an important interdependency between the two systems. | Yes | Yes |
| ACH Processing or File Integrity Failure | Processing errors, corrupted files, or interface failures could result in delayed, rejected, duplicated, or inaccurate clearing instructions. | Yes | Yes |
| CSD System Disruption | CSD failure could disrupt securities recordkeeping and activities associated with government securities, including transfers and other supported market processes. | Yes | Yes |
| CSD Data Integrity Failure | Incorrect or corrupted securities records could create uncertainty concerning holdings, transfers, or related transactions and require controlled reconciliation before normal processing resumes. | Yes | Yes |
| Combined RTGS and ACH Failure | A common infrastructure, dependency, or technology event affecting RTGS and ACH simultaneously could create broader disruption to payment clearing and settlement. | Yes | Yes |
| Multiple NPSS Component Failure | Simultaneous or cascading failure affecting RTGS, ACH, and/or CSD could create significant operational and financial-sector consequences and require immediate strategic Crisis Management. | Yes | Yes |
| Payment-System Reconciliation Failure | Technology or data problems could prevent timely reconciliation of transactions and balances, creating uncertainty about processing completeness and accuracy. | Yes | Yes |
| Payment-System Capacity Failure | Transaction volumes or technical problems could exceed available processing capacity, creating backlogs and delayed settlement during critical periods. | Yes | Yes |
| Payment-System Dependency Failure | Failures in supporting networks, databases, authentication, telecommunications, utilities, or external providers could disrupt payment systems even if the core application remains functional. | Yes | Yes |
| Power Supply Failure Affecting Technology | Prolonged loss or instability of electrical power could affect data centres, networks, user environments, and supporting technology infrastructure. | Yes | Yes |
| UPS Failure | Failure of uninterruptible power supplies could remove the immediate bridge between utility loss and generator availability, resulting in abrupt equipment shutdown. | Potential | Yes |
| Backup Generator Failure | Failure of emergency generation during prolonged utility loss could make technology facilities unsustainable and lead to service interruption. | Potential | Yes |
| Cooling/HVAC Failure | Loss of cooling at technology facilities could cause equipment to overheat, shut down automatically, or sustain physical damage to critical infrastructure. | Potential | Yes |
| Environmental Monitoring Failure | Failure to detect temperature, humidity, water leakage, smoke, or other environmental conditions could allow a facility's problem to damage technology before corrective action is taken. | Potential | Yes |
| Fire Suppression System Malfunction Affecting IT | Failure or accidental activation of fire-suppression systems could damage equipment or require shutdown of technology environments. | Potential | Yes |
| Physical Cable or Fibre Damage | Accidental construction damage, equipment failure, or other physical events affecting telecommunications or data links could isolate BDCB sites or external participants. | Yes | Yes |
| Single Point of Failure | An unidentified or inadequately controlled single dependency could cause disproportionate service interruption when one component, system, person, or provider fails. | Potential | Yes |
| Common-Mode Technology Failure | Multiple supposedly redundant components may fail simultaneously because they share the same software, power supply, network, provider, configuration, or physical location. | Yes | Yes |
| Dependency Mapping Failure | An incomplete understanding of application and infrastructure dependencies could result in recovering individual systems without restoring the end-to-end service. | Potential | Yes |
| Recovery Sequence Failure | Systems restored in the wrong order could remain unusable or cause processing and data-integrity problems because prerequisite services are unavailable. | Potential | Yes |
| Recovery Capacity Shortfall | Recovery infrastructure may function but lack sufficient processing, storage, network, or user capacity to support required operations during an extended disruption. | Potential | Yes |
| Technology Recovery Personnel Unavailability | Critical specialists may be unavailable during a major outage, delaying diagnosis, failover, restoration, or vendor coordination. | Potential | Yes |
| Technology Documentation Failure | Missing, inaccurate, or inaccessible architecture diagrams, configurations, recovery procedures, or credentials could materially delay technology recovery. | Potential | Yes |
| Asset/Configuration Information Failure | Inaccurate inventories or configuration records could prevent responders from understanding affected assets, dependencies, or recovery requirements. | Potential | Yes |
| Monitoring and Control Room Technology Failure | Failure of technology used to monitor payment, infrastructure, or operational conditions could reduce situational awareness during another incident. | Potential | Yes |
| Crisis Communication Technology Failure | Failure of telephony, conferencing, messaging, or other emergency communication technology during a crisis could impair CMT coordination and stakeholder engagement. | Potential | Yes |
| Multiple Concurrent Technology Failures | Two or more independent or correlated failures could overwhelm normal recovery arrangements, create competing priorities, and significantly increase restoration complexity. | Yes | Yes |
| Cascading Technology Failure | Failure of one critical component could propagate through interconnected applications, networks, infrastructure, and external services, creating progressively wider disruption. | Yes | Yes |
| Technology Failure During Financial-Sector Stress | A technology disruption occurring simultaneously with liquidity, market, or institution-specific stress could amplify financial-sector consequences and reduce management options. | Yes | Yes |
| Technology Failure During National Emergency | Technology disruption during severe weather, public-health emergency, security incident, or another national event could compound workforce, telecommunications, and supplier constraints. | Yes | Yes |
| Emerging Technology Failure | Failure, instability, or unforeseen behaviour in newly introduced technologies could disrupt operations before organisational experience, controls, and recovery capability have matured. | Potential | Yes |
| Artificial Intelligence System Failure | Where AI-enabled systems support BDCB activities, erroneous output, model failure, unavailable AI services, or integration problems could affect decisions or processes that rely too heavily on the technology. | Potential | Yes |
| AI Model/Data Integrity Failure | Incorrect, corrupted, biased, or unsuitable data used by an AI-enabled capability could generate unreliable outputs while the underlying system appears operational. | Potential | Yes |
| Critical Technology Obsolescence | Growing reliance on technology for which skills, replacement components, or vendor support are increasingly unavailable could materially increase disruption and recovery risk. | Potential | Yes |

#### **Key Technology Threat Clusters for BDCB**

For practical Crisis Risk Assessment, the detailed threats above can be consolidated into **twelve technology threat clusters**:

 

| Technology Threat Cluster | Principal Concern |
| --- | --- |
| 1. Hardware and Infrastructure | Physical failure of computing infrastructure |
| 2. Applications and Databases | Loss or corruption of critical application services |
| 3. Networks and Telecommunications | Loss of internal or external connectivity |
| 4. Data and Transaction Integrity | Inability to trust information or transaction records |
| 5. Identity and Security Infrastructure | Loss of legitimate system access or security-supporting services |
| 6. Data Centre and Facilities Technology | Loss of technology environments or supporting utilities |
| 7. Disaster Recovery and Backup | Inability to recover within the required time and data objectives |
| 8. Change and Configuration | Disruption caused by changes, upgrades, migrations, or configuration errors |
| 9. Capacity and Performance | Technology remains technically available, but cannot support the required demand |
| 10. Third-Party and Cloud Technology | Failure of technology outside BDCB's direct operational control |
| 11. National Payment and Settlement Systems | Disruption to RTGS, ACH, CSD, or their dependencies |
| 12. Emerging and Systemic Technology | Common-mode, cascading, concurrent, and emerging-technology failures |

This grouping allows BDCB to maintain a comprehensive threat catalogue without requiring every individual technical failure mode to become a separate Crisis Management scenario.

#### **Distinguishing Technology Incidents from Technology Crises**

Not every technology failure should activate BDCB's Crisis Management Team.

A useful escalation pathway is:

**Technology Fault → Technology Incident → Critical Service Disruption → Multiple Dependencies or Stakeholders Affected → Strategic Consequences → Technology Crisis**

The transition from an **IT incident** to a **strategic crisis** may occur when one or more of the following conditions arise:

- critical BDCB activities cannot be sustained;
- RTGS, ACH or CSD is materially affected;
- transaction or data integrity cannot be established;
- multiple financial institutions are affected;
- recovery time becomes highly uncertain;
- primary and recovery arrangements are simultaneously impaired;
- important financial-sector dependencies are disrupted;
- senior-level decisions are required;
- government or other authorities require coordination;
- public or market confidence could be affected;
- misinformation is increasing consequences; or
- financial stability could be affected.

This distinction prevents the CMT from becoming involved in routine IT incidents while ensuring that technology events with strategic consequences are escalated promptly.

#### **Availability Versus Integrity**

For a central bank, one of the most important distinctions in technology crisis assessment is between **availability** and **integrity**.

**System Availability — Can BDCB access and operate the system?**

**System Integrity — Can BDCB trust the information and transactions produced by the system?**

An unavailable system may have a reasonably predictable recovery path.

A system that is available but producing unreliable transactions or corrupted information can create a more difficult Crisis Management problem because continuing operation may increase the consequences.

This is particularly important for payment and settlement infrastructure.

#### **Cascading Technology Consequences**

Do not assess technology threats solely by the failed technical component. BDCB should consider how consequences propagate.

**Technology Failure → Application or Infrastructure Disruption → BDCB Critical Activity Affected → Financial Institution or Participant Affected → Financial Service Disrupted → Businesses and Consumers Affected → Confidence Consequences → Potential Financial-System Impact**

A relatively small technical fault could therefore become a significant crisis because of its position within an important dependency chain.

#### **Technology Interdependencies**

A technology Crisis Risk Assessment should explicitly examine:

**Power + Cooling + Data Centre + Hardware + Network + Telecommunications + Identity Services + Applications + Databases + External Providers + Skilled Personnel**

Failure of any one of these may affect the availability of the end-to-end service.

For the NPSS environment, assessment should extend further:

**Supporting Infrastructure → BDCB Technology → RTGS/ACH/CSD → Financial Institutions → Payment and Settlement Activities → Businesses and Consumers → Financial-System Confidence**

This is why technology resilience should be assessed from an **end-to-end service perspective**, rather than system by system.

#### **Relationship with Cyber Threats**

Technology and cyber threats frequently overlap, but should not automatically be treated as identical.

A technology disruption may result from:

- equipment failure;
- software defect;
- configuration error;
- capacity problem;
- environmental failure;
- supplier outage;
- human error; or
- cyberattack.

The immediate symptoms may nevertheless be similar.

For example:

**System Unavailable → Cause Unknown → Technology Investigation → Cyber Cause Confirmed or Excluded → Appropriate Specialist Response**

Until the cause is established, BDCB should avoid assuming that a serious unexplained technology failure is purely technical.

Where malicious cyber activity is suspected or confirmed, the incident should also be assessed through BDCB's cyber-response and Crisis Management arrangements.

#### **Applying the Catalogue to the Crisis Risk Assessment**

The threat catalogue should inform the subsequent CRA activities.

The recommended progression is:

**Technology Threat Catalogue → Scenario Selection → Existing Controls → Additional Controls → Impact Assessment → Likelihood Assessment → Risk Rating → Crisis Preparedness Priority**

BDCB does not necessarily need a detailed Crisis Management playbook for every row in the catalogue. Instead, threats with similar consequences can be grouped into representative scenarios.

For example, hardware, operating-system and virtualisation failures might contribute to a broader scenario titled **“Critical Technology Platform Failure.”**

Likewise, multiple payment-system failure modes could be represented through scenarios such as:

- Major RTGS Disruption;
- Major ACH Disruption;
- Major CSD Disruption;
- Payment-System Data Integrity Crisis;
- Combined Payment Infrastructure Failure; and
- Participant Connectivity Crisis.

This provides sufficient detail for risk identification without unnecessarily complicating Crisis Management arrangements.

 

[![Banner \[CM\] \[Summing Up\] \[E3\] \[CRA\] \[P1-3\] List of Crisis Scenarios \[Technology\]](https://no-cache.hubspot.com/cta/default/3893111/99097b2b-f1f1-456c-b7f6-fa3e3decf150.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/99097b2b-f1f1-456c-b7f6-fa3e3decf150)

Technology risk represents one of the most significant sources of potential operational and strategic crises for **Brunei Darussalam Central Bank** because technology underpins BDCB's internal activities, information, communications, and important financial-market infrastructure.

In particular, disruption to RTGS, ACH, or CSD could extend beyond an internal technology problem and affect financial institutions, settlement activities, businesses, consumers, and potentially financial system confidence.

BDCB's published information confirms the important role of these systems within Brunei Darussalam's National Payment and Settlement Systems.

The technological threat landscape should therefore be assessed from an **end-to-end perspective**.

Hardware, applications, databases, networks, telecommunications, data centres, utilities, identity services, third parties, cloud platforms, recovery environments, and skilled personnel form interconnected dependencies.

Failure in one area can propagate into others, while common-mode or cascading failures can defeat apparently resilient arrangements.

Particular attention should be paid to **data and transaction integrity**.

For a central bank, knowing that a system is available is not sufficient; BDCB must also be able to establish that important information and transactions remain complete, accurate, and trustworthy. Where integrity cannot be established, the strategic consequences may exceed those of straightforward system unavailability.

The catalogue in CRA Part 1-3 should consequently be treated as the starting point for further assessment rather than as a completed risk assessment.

Each applicable threat should proceed through BDCB's Crisis Risk Analysis process to determine existing controls, additional controls, impact, likelihood, residual risk, and preparedness requirements.

The overall implementation pathway is:

**Identify Technology Threats → Understand Dependencies → Develop Credible Crisis Scenarios → Assess Existing Controls → Evaluate Impact and Likelihood → Determine Risk → Prioritise Treatment → Prepare Response and Recovery → Exercise → Review and Improve**

The desired outcome is not the elimination of every technology failure.

It is the development of sufficient **technology resilience, recovery capability, and strategic Crisis Management preparedness** so that BDCB can prevent foreseeable failures where practicable, detect emerging problems early, contain disruption, preserve information and transaction integrity, recover critical services, and manage wider financial-sector consequences before a technology incident develops into a major strategic crisis.

 

**[![\[CM\] \[BDCB\] \[3/4 Banner\] Crisis Management in Action\_ A Practical Implementation Guide for BDCB](https://no-cache.hubspot.com/cta/default/3893111/b3d8c34f-d579-45e8-aba7-c04de5f90bb2.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/b3d8c34f-d579-45e8-aba7-c04de5f90bb2)**

| **eBook 3: Starting Your CM Implementation** |  |  |  |
| --- | --- | --- | --- |
| \[RAR\] \[P1-1\] | \[RAR\] \[P1-2\] | \[RAR\] \[P1-3\] | \[RAR\] \[P2\] |
| [![\[CM\] \[BDCB\] \[E3\] \[CRA\] \[P1-1\] List of Threats](https://no-cache.hubspot.com/cta/default/3893111/aca43cda-9319-49d4-81cf-9ec36c6c6ab6.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/aca43cda-9319-49d4-81cf-9ec36c6c6ab6) | [![\[CM\] \[BDCB\] \[E3\] \[CRA\] \[P1-2\] List of Crisis Scenarios \[Natural and Man-made\]](https://no-cache.hubspot.com/cta/default/3893111/029d6134-feb9-446e-884c-562eb4fd8e70.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/029d6134-feb9-446e-884c-562eb4fd8e70) | [![\[CM\] \[BDCB\] \[E3\] \[CRA\] \[P1-3\] List of Crisis Scenarios \[Technology\] ](https://no-cache.hubspot.com/cta/default/3893111/883a9c65-15e5-408d-a406-3835732e8f16.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/883a9c65-15e5-408d-a406-3835732e8f16) | [![\[CM\] \[BDCB\] \[E3\] \[RAR\] \[P2\] Treatment and Control](https://no-cache.hubspot.com/cta/default/3893111/a122225c-4e8c-435a-8268-4e24d1d834bf.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/a122225c-4e8c-435a-8268-4e24d1d834bf) |
| \[RAR\] \[P3\] | \[CMS\] \[P1\] | \[CMS\] \[P2\] | eBook 3 |
| [![\[CM\] \[BDCB\] \[E3\] \[CRA\] \[P3\] Risk Impact and Likelihood Assessment](https://no-cache.hubspot.com/cta/default/3893111/7a44ac98-15cf-427b-b8fa-011061502369.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/7a44ac98-15cf-427b-b8fa-011061502369) | [![\[CM\] \[BDCB\] \[E3\] \[CMS\] \[P1\] Crisis Prevention Strategy](https://no-cache.hubspot.com/cta/default/3893111/8e764d9a-b2ac-4551-b953-7f5bec6e662d.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/8e764d9a-b2ac-4551-b953-7f5bec6e662d) | [![\[CM\] \[BDCB\] \[E3\] \[CMS\] \[P2\] Crisis Response Strategy](https://no-cache.hubspot.com/cta/default/3893111/0dacc52b-d723-44a2-999f-66752a10d897.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/0dacc52b-d723-44a2-999f-66752a10d897) | [![eBook Cover \[CM\] \[BDCB\] \[E3\] \[2D\]](https://no-cache.hubspot.com/cta/default/3893111/77f3104a-2f3b-4e2b-a101-9e72c37001c2.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/77f3104a-2f3b-4e2b-a101-9e72c37001c2) |
|  |  |  |  |

 

#### More Information About Crisis Management Blended/ Hybrid Learning Courses

To learn more about the course and schedule, click the buttons below for the  CM-300 Crisis Management Implementer \[CM-3\] and the CM-5000 Crisis Management Expert Implementer \[CM-5\].

| [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/5ffecd2d-8000-4805-b5e3-e9ead2e259cc.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/5ffecd2d-8000-4805-b5e3-e9ead2e259cc) | [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/c3546220-6c76-4a10-8c76-4040b94e09e5.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/c3546220-6c76-4a10-8c76-4040b94e09e5) | [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/03294547-1df3-435c-9243-971c3d9bb6ce.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/03294547-1df3-435c-9243-971c3d9bb6ce) |
| --- | --- | --- |
| [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/b29594fe-d44a-4ff8-8160-03f7ce454385.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/b29594fe-d44a-4ff8-8160-03f7ce454385) | [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/dd120e7f-9fe2-49ed-ad24-489b81c06739.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/dd120e7f-9fe2-49ed-ad24-489b81c06739) | [![\[BL-CM\] \[5\] Register](https://no-cache.hubspot.com/cta/default/3893111/82024308-16f4-4491-98be-818a882c6286.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/82024308-16f4-4491-98be-818a882c6286) |
| [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/c8aaf76b-4c0b-402a-ad12-c8aff24eb911.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/c8aaf76b-4c0b-402a-ad12-c8aff24eb911) | Please feel free to send us a note if you have any questions. [![Email to Sales Team \[BCM Institute\]](https://no-cache.hubspot.com/cta/default/3893111/3c53daeb-2836-4843-b0e0-645baee2ab9e.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/3c53daeb-2836-4843-b0e0-645baee2ab9e) | [![FAQ BL-CM-5 CM-5000](https://no-cache.hubspot.com/cta/default/3893111/30bcbbbf-c8ea-48d8-8643-da2638f3f0f8.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/30bcbbbf-c8ea-48d8-8643-da2638f3f0f8) |
| [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/83d00c12-c51c-4476-9902-69f9b7667a91.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/83d00c12-c51c-4476-9902-69f9b7667a91) | [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/672d2949-6233-4b26-ad42-ae0dd0a1a3ac.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/672d2949-6233-4b26-ad42-ae0dd0a1a3ac) | [![New call-to-action](https://no-cache.hubspot.com/cta/default/3893111/3ca6f50d-a3c5-41b8-8da2-26feb8a7613e.png)](https://cta-redirect.hubspot.com/cta/redirect/3893111/3ca6f50d-a3c5-41b8-8da2-26feb8a7613e) |

### Your Comments Here:

 

![CTA Banner\_OR](https://blog.bcm-institute.org/hubfs/CTA%20Banner%20for%20Blog/CTA%20Banner_OR.jpg "CTA Banner_OR")

---

![CTA Banner\_ORA](https://blog.bcm-institute.org/hubfs/CTA%20Banner%20for%20Blog/CTA%20Banner_ORA.jpg "CTA Banner_ORA")

---

![CTA Banner\_BCM](https://blog.bcm-institute.org/hubfs/CTA%20Banner%20for%20Blog/CTA%20Banner_BCM.jpg "CTA Banner_BCM")

---

![CTA Banner\_ITDR](https://blog.bcm-institute.org/hubfs/CTA%20Banner%20for%20Blog/CTA%20Banner_ITDR.jpg "CTA Banner_ITDR")

---

![CTA Banner\_CM](https://blog.bcm-institute.org/hubfs/CTA%20Banner%20for%20Blog/CTA%20Banner_CM.jpg "CTA Banner_CM")

![BCMIWhiteLogoSmall.png](https://blog.bcm-institute.org/hs-fs/hubfs/Blog%20Testing/BCMIWhiteLogoSmall.png?width=72&name=BCMIWhiteLogoSmall.png "BCMIWhiteLogoSmall.png")

All rights reserved. Copyright 2026

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Moh Heng Goh",
    "url" : "https://blog.bcm-institute.org/en/ebook-cm/author/moh-heng-goh"
  },
  "dateModified" : "2026-10-09T08:13:43.081Z",
  "datePublished" : "2026-10-07T08:20:05.000Z",
  "headline" : "[CM] [BDCB] [E3] [CRA] [P1-3] List of Crisis Scenarios [Technology]",
  "mainEntityOfPage" : {
    "@id" : "https://blog.bcm-institute.org/en/ebook-cm/cm-bdcb-e3-cra-p1-3-list-of-crisis-scenarios-technology",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://blog.bcm-institute.org/hubfs/BCMI%20Logo.png"
    },
    "name" : "BCMI Pte Ltd"
  }
}
```