It should examine how an incident develops, affects interconnected processes and resources, and could cause unacceptable harm to depositors, member banks, PIDM, or the wider financial system.
The 18 identified Sub-Critical Business Services (Sub-CBS) provide the operational foundation for this assessment.
They allow PIDM to identify where disruption originates, how it propagates through membership administration, coverage determination, deposit information management, premium administration and communication, and which capabilities must remain available.
Cyber and ICT risks are integrated into each scenario as potential triggers, contributing factors or disruption amplifiers.
The scenarios also address people, facilities, external institutions, operational decisions and recovery failures. Their purpose is to challenge the effectiveness of existing or proposed controls and establish whether CBS-1 can remain within its approved Impact Tolerance.
Scope clarification: The supplied catalogue contains 18 Sub-CBS processes, numbered CBS-1.1 to CBS-1.18, although the quality-control instructions refer to 20. Both assessment tables below cover all 18 supplied processes and introduce no unapproved additions.
PIDM's actual systems, providers, operating procedures and controls have not been verified. Accordingly, the scenarios and proposed measures are illustrative implementation material, not findings about existing weaknesses.
A useful scenario should describe a disruptive event, its operating context, the failure pathway, the resulting service consequences, and the management decisions needed to contain harm.
For CBS-1, scenario design should consider two distinct operating states:
The same disruption may have different consequences in these two states.
A temporary information exchange failure might be manageable during routine administration, but materially impair preparedness or communication during a member bank failure.
The preceding impact tolerance chapter proposed the following illustrative thresholds. They are carried forward solely to provide a consistent basis for scenario design.
|
Dimension |
Proposed assessment threshold |
|
Normal operating conditions |
Maximum 24 hours of disruption to essential CBS-1 administration. |
|
Heightened financial stress |
Maximum four hours of disruption to essential protection information and administrative capabilities. |
|
Information integrity |
No knowingly released materially incorrect authoritative protection decisions or coverage information. |
|
Minimum operating capacity |
Illustrative minimum of 50% of required essential workload, subject to validation. |
|
Information currency |
Illustrative four-hour availability threshold for approved essential membership and coverage changes during heightened stress. |
|
Statutory obligations |
No material breach of applicable statutory obligations or deadlines. |
|
Connected services |
CBS-1 disruption must not cause another CBS to exceed its own approved tolerance. |
|
Restoration |
Verify and reconcile essential information and transactions before unrestricted resumption. |
These are not approved PIDM tolerances or BNM-prescribed limits. PIDM must validate them against actual harm, statutory requirements, service volumes, and recovery capabilities.
In the tables below, a potential breach means that the scenario could cross one or more of these provisional boundaries; it does not imply that a breach is inevitable.
The scenarios below cover the full CBS-1 lifecycle. Each combines a credible disruptive event with an operational circumstance that makes the consequences severe.
The descriptions distinguish the initiating event from its effects on the individual Sub-CBS and the wider service.
|
Sub-CBS Code |
Name of Sub-CBS |
Recommended Severe but Plausible Scenario |
Scenario Description |
Primary Disruption Trigger |
Impact on Sub-CBS |
Impact on Critical Business Service |
|
CBS-1.1 |
Administer Member Bank Participation |
Conflicting membership status during an urgent institutional change |
An urgent change in a member bank's status occurs while PIDM's membership register is inaccessible. Information received through alternative channels conflicts with the last verified record, and authorised decision-makers cannot immediately confirm the effective status. |
Membership database failure coinciding with an urgent institutional status change. |
Membership updates cannot be validated or issued with confidence. |
Premium, compliance and protection information may rely on inconsistent membership records; uncertainty could spread to CBS-7 and CBS-9. |
|
CBS-1.2 |
Maintain Deposit Insurance Coverage Framework |
Compromised coverage rules distributed across administrative processes |
An unauthorised alteration to a controlled coverage document is replicated to assessment and publication repositories. The error is detected only after several downstream decisions have been prepared. |
Compromise of privileged document access or a failed rules publication change. |
Staff cannot establish which coverage rules are authoritative without independent verification. |
Product assessments, coverage records and protection information may become inconsistent; materially incorrect decisions could create immediate unacceptable harm. |
|
CBS-1.3 |
Assess Deposit Product Insurability |
Surge in complex product assessments during specialist unavailability |
Several member banks seek urgent clarification of product eligibility during financial stress. Key legal and assessment specialists are unavailable, while an assessment workflow upgrade prevents access to previous determinations. |
Concurrent specialist absence and failed application deployment during a demand surge. |
Product classifications accumulate without sufficiently authorised review. |
Delayed or inconsistent eligibility determinations impair coverage records and member bank disclosures when clarity is particularly important. |
|
CBS-1.4 |
Administer Deposit Product Coverage Records |
Silent corruption of authoritative product classifications |
A faulty data migration changes product coverage attributes without generating immediate system errors. Updated records are distributed before reconciliation identifies the discrepancies. |
Failed data migration and ineffective integrity controls. |
Coverage records remain accessible but cannot be trusted. |
Incorrect classifications may propagate into disclosures, depositor responses and reimbursement-related information. |
|
CBS-1.5 |
Administer Member Bank Deposit Information Requirements |
Inconsistent reporting specifications during a regulatory or administrative change |
A revised reporting specification is approved, but a communication platform outage causes different member banks to receive different versions. A scheduled reporting cycle begins before the discrepancy is identified. |
Failed controlled distribution compounded by telecommunications disruption. |
Reporting requirements are inconsistently communicated, and submissions become incompatible. |
Multiple banks' information may be rejected or delayed, disrupting validation, insured deposit assessment and premium administration. |
|
CBS-1.6 |
Receive and Validate Deposit Insurance Information |
Coordinated submission-channel disruption during peak reporting |
A denial-of-service incident overwhelms the member bank submission gateway while malicious or malformed files trigger additional validation failures. The reporting deadline approaches, and alternative submission capacity is limited. |
Cyberattack against an information exchange service, amplified by peak workload. |
Information cannot be received or reliably validated at the required rate. |
Essential information becomes stale, downstream processing stops and the service may breach duration, capacity or statutory conditions. |
|
CBS-1.7 |
Maintain Insured Deposit Information and Records |
Ransomware compromises production records and accessible backups |
Ransomware encrypts the authoritative information repository. Investigation reveals that recent backups share compromised credentials and may contain altered records. |
Ransomware and compromised recovery dependencies. |
PIDM loses reliable access to current deposit information and cannot immediately establish a clean recovery point. |
Validation, premium administration and relevant reimbursement preparedness may be impaired for an extended period; restoring unverified data could breach integrity conditions. |
|
CBS-1.8 |
Validate Total Insured Deposits |
Systematic miscalculation remains undetected across several banks |
A validation rule change produces incorrect insured deposit totals for multiple member banks. Automated checks compare results against similarly affected data, so the discrepancy is discovered only during an independent review. |
Defective calculation logic and correlated validation controls. |
Total insured deposits cannot be confirmed without recalculation. |
Premium assessments may be misstated and administrative information may require extensive correction, potentially affecting critical deadlines. |
|
CBS-1.9 |
Assess Member Bank Premium Classification |
Incorrect premium classifications after a compromised assessment input |
A material assessment input is altered or incorrectly imported shortly before classification approval. Several classifications are issued before inconsistencies are detected. |
Compromised assessment data or failed data import. |
Premium classifications must be suspended, investigated and reassessed. |
Incorrect premium obligations and member bank disputes may spread into calculation, collection and compliance processes. |
|
CBS-1.10 |
Calculate and Assess Deposit Insurance Premiums |
Premium calculation failure immediately before an applicable deadline |
A software release changes the premium calculation logic during the assessment cycle. Rollback fails because supporting data structures have also changed, while the assessment deadline is approaching. |
Failed technology change and unsuccessful rollback. |
Premium assessments cannot be completed or independently verified. |
Material premium obligations may be delayed or misstated, potentially breaching applicable deadlines and financial integrity conditions. |
|
CBS-1.11 |
Administer Premium Collection and Reconciliation |
Payment confirmation outage combined with suspected fraudulent instructions |
A banking interface stops delivering payment confirmations. At the same time, an apparently authorised message requests a change to payment details, creating uncertainty over which receipts and instructions are genuine. |
Banking connectivity failure compounded by attempted payment-information compromise. |
Collections cannot be confidently matched to obligations; disputed transactions require investigation. |
Unreconciled premiums and unreliable financial records may prevent PIDM from confirming member bank obligations. |
|
CBS-1.12 |
Monitor Member Bank Compliance with Deposit Insurance Requirements |
Compliance breaches concealed by incomplete reporting feeds |
A reporting interface silently stops transferring premium and disclosure exceptions. The compliance dashboard continues displaying apparently normal results while material cases accumulate. |
Data feed failure and ineffective monitoring of reporting completeness. |
Compliance officers cannot identify or escalate significant outstanding obligations. |
Prolonged non-compliance may remain undetected, affecting the reliability and integrity of deposit insurance administration. |
|
CBS-1.13 |
Administer Deposit Insurance Disclosure Requirements |
Widespread publication of incorrect protection disclosures |
An outdated disclosure template is distributed to several member banks following a failed content update. The error becomes apparent during heightened depositor enquiries. |
Failed publication control and outdated content replication. |
Disclosure requirements and published materials become inconsistent with approved coverage information. |
Depositors may receive materially incorrect protection information, creating potential immediate integrity and confidence consequences. |
|
CBS-1.14 |
Provide Deposit Insurance Protection Information |
Loss of authoritative information channels during member bank distress |
A member bank distress event triggers a surge in depositor enquiries. PIDM's public website becomes unavailable under a denial-of-service attack, while a telecommunications failure disrupts its primary enquiry channel. |
Concurrent cyberattack, telecommunications failure and demand surge. |
Authoritative information cannot be delivered at sufficient capacity through normal channels. |
Depositors may be unable to obtain verified information during a sensitive event, threatening heightened-stress tolerance and increasing uncertainty. |
|
CBS-1.15 |
Manage Deposit Insurance Administrative Exceptions |
Critical exception backlog after simultaneous processing errors |
A data processing defect creates a large volume of coverage and premium discrepancies. The case management platform becomes unavailable, preventing staff from tracking affected decisions and assigning corrective action. |
Processing defect amplified by case management system failure. |
Critical exceptions cannot be prioritised, resolved or reliably tracked. |
Uncorrected errors may propagate into premium assessments, disclosures and compliance decisions. |
|
CBS-1.16 |
Monitor Deposit Insurance Service Performance |
Monitoring blind spot masks widespread service deterioration |
A monitoring platform upgrade disables several operational alerts. A separate time synchronisation failure makes event records inconsistent, delaying recognition of growing submission failures and processing backlogs. |
Failed monitoring change and time synchronisation failure. |
Performance deterioration is not detected or escalated promptly. |
Several Sub-CBS processes may degrade simultaneously until CBS-1 exceeds its approved capacity or duration limits. |
|
CBS-1.17 |
Manage Deposit Insurance Service Disruptions |
Crisis coordination fails during a compound cyber and facilities incident |
A cyber incident disables administrative systems while a regional infrastructure disruption prevents access to the primary coordination location. Normal communications are unavailable, and designated decision-makers cannot be reached promptly. |
Concurrent cyber incident, facilities disruption and communications failure. |
Continuity activation, prioritisation, escalation and stakeholder coordination are delayed. |
A potentially containable incident spreads across CBS-1 and connected services, increasing the likelihood of an impact tolerance breach. |
|
CBS-1.18 |
Restore and Reconcile Deposit Insurance Administration |
Apparent technology recovery conceals incomplete records |
Following a major outage, recovery applications become available within their technical recovery targets. However, transaction logs reveal missing updates and inconsistent premium records; pressure to resume normal processing increases. |
Failed recovery data replication and incomplete reconciliation. |
Staff cannot confirm that restored information and outstanding transactions are complete. |
CBS-1 remains operationally impaired despite system availability; premature resumption could breach integrity and restoration conditions. |
The proposed scenarios deliberately cover different failure mechanisms: incorrect institutional information, legal and policy integrity, specialist unavailability, defective changes, cyberattack, external connectivity, financial processing, monitoring failure, crisis coordination and incomplete recovery.
They also test circumstances in which systems remain technically available but the service cannot safely be delivered.
This distinction matters for deposit insurance administration, where inaccurate information may cause harm before an availability target is exceeded.
Table 2 translates each scenario into a testable resilience assessment.
It identifies the connections that may transmit disruption, explains the role of cyber and ICT risks, and specifies actions and evidence that PIDM should use to demonstrate preparedness.
Control terminology: Preventive controls reduce the likelihood of failure; detective controls identify deterioration; response controls contain the incident; recovery controls restore service; and resilience measures preserve essential outcomes while disruption continues.
The measures and evidence below are proposed requirements for PIDM's implementation programme. Verify their existence and effectiveness.
|
Sub-CBS Code |
Name of Sub-CBS |
Interconnections and Interdependencies Challenged |
Cyber and ICT Risk Linkage |
Potential Impact Tolerance Breach |
Proactive Risk Management Action |
Evidence of Proactive Risk Management |
Scenario Testing Objective |
|
CBS-1.1 |
Administer Member Bank Participation |
Authoritative institutional status from BNM and member banks; membership register; legal approvals; hand-offs to CBS-1.5, CBS-1.9, CBS-1.12 and CBS-7. |
Trigger/amplifier: Database failure or compromised access prevents verification of status. Failed replication may also make alternative records inconsistent. |
Yes, conditional. A material status error could immediately breach integrity conditions; prolonged inability to confirm status during distress could exceed the four-hour stress threshold. |
Prevent: Dual approval and protected status records. Detect: Reconcile institutional changes against authoritative notices. Respond: Activate legal verification and controlled provisional handling. Recover: Restore and reconcile the register. |
Approved membership procedures; status reconciliation records; access reviews; alternative verification exercise; recovery test and decision logs. |
Demonstrate that PIDM can verify an urgent status change, prevent unapproved downstream updates and restore a consistent authoritative register within tolerance. |
|
CBS-1.2 |
Maintain Deposit Insurance Coverage Framework |
Statutory provisions; legal interpretation; approved rules repository; product assessment; coverage records; CBS-2 and CBS-9. |
Trigger: Privileged account compromise or faulty publication modifies the rules. Amplifier: Automated distribution replicates the error. |
Yes. Materially incorrect authoritative coverage guidance could violate the zero-material-error condition before any duration threshold expires. |
Prevent: Segregated rule authoring and approval, signed versions and restricted publication rights. Detect: Independent integrity comparison. Respond: Withdraw suspect rules and suspend affected decisions. Recover: Republish verified rules and reassess affected outputs. |
Signed rule versions; legal approvals; repository audit logs; integrity test results; withdrawal exercise; downstream correction records. |
Verify detection, containment and correction of a compromised rule before it is relied upon for material protection decisions. |
|
CBS-1.3 |
Assess Deposit Product Insurability |
Member bank product documents; legal specialists; assessment workflow; CBS-1.2 and CBS-1.4; disclosure and enquiry processes. |
Amplifier: Failed application change removes access to prior assessments. Phishing or altered submissions could also compromise the assessment evidence. |
Yes, conditional. A growing backlog may breach capacity or duration limits; an incorrect classification could breach the integrity condition. |
Prevent: Maintain approved assessment criteria and trained deputies. Detect: Track assessment age and quality. Respond: Prioritise urgent products and use controlled offline assessment. Recover: Reconcile decisions into the system. |
Competency and deputisation records; backlog reports; assessment quality reviews; change test results; offline workflow exercise. |
Establish whether a surge can be managed without unauthorised determinations or unacceptable delays when specialists and the workflow are unavailable. |
|
CBS-1.4 |
Administer Deposit Product Coverage Records |
Approved classifications from CBS-1.3; product register; disclosure content; CBS-2 and CBS-9; backup and data management capabilities. |
Trigger: Faulty migration. Amplifier: Corrupted records replicate to downstream repositories and backups before detection. |
Yes. Publishing or using materially incorrect coverage records would breach integrity conditions, regardless of system uptime. |
Prevent: Pre-migration reconciliation, controlled releases and immutable historical versions. Detect: Record-level integrity checks. Respond: Quarantine affected records. Recover: Restore a verified version and correct downstream copies. |
Migration approval; source-to-target reconciliation; integrity alerts; backup tests; affected-record register; correction sign-offs. |
Demonstrate that silent corruption can be detected, isolated and reversed without releasing incorrect classifications. |
|
CBS-1.5 |
Administer Member Bank Deposit Information Requirements |
Coverage and membership rules; reporting specifications; secure member communication; CBS-1.6; CBS-10. |
Trigger/amplifier: Telecommunications outage or document publication failure creates inconsistent specifications. |
Yes, conditional. Broad submission failures could exceed the 24-hour threshold or cause an applicable deadline to be missed. |
Prevent: Version-controlled specifications and authenticated distribution. Detect: Member acknowledgement and version checks. Respond: Issue a single authoritative clarification through alternate channels. Recover: Reconcile submissions against the correct specification. |
Distribution logs; version register; member acknowledgements; alternate-channel tests; correction notices; submission reconciliation. |
Verify that all affected banks can obtain the same approved requirements and resume compliant submissions despite primary-channel failure. |
|
CBS-1.6 |
Receive and Validate Deposit Insurance Information |
Member bank submissions; secure transfer gateway; validation rules; CBS-1.7 and CBS-1.8; CBS-10; hosting and network providers. |
Trigger: Denial-of-service attack. Amplifiers: Malformed files, capacity exhaustion and failure of the alternate transfer channel. |
Yes. Prolonged loss of submissions, materially corrupted accepted data or missed deadlines could breach duration, integrity or statutory conditions. |
Prevent: Traffic protection, secure file handling and tested capacity. Detect: Submission completeness and validation alerts. Respond: Activate prioritised alternate submissions. Recover: Reprocess and reconcile queued files. |
Capacity and security test reports; submission monitoring; alternate transfer exercise; validation results; backlog clearance records. |
Demonstrate that essential submissions can be received, verified and processed within tolerance during a coordinated attack and reporting peak. |
|
CBS-1.7 |
Maintain Insured Deposit Information and Records |
Accepted submissions; authoritative repository; access management; backups; CBS-1.8, CBS-1.10, CBS-2 and CBS-6. |
Trigger: Ransomware. Amplifiers: Compromised privileged credentials, shared backup access and replication of corrupted data. |
Yes. Unrecoverable records, material data errors or prolonged repository unavailability could breach multiple tolerance dimensions. |
Prevent: Privileged access controls, segmentation and isolated backups. Detect: Integrity monitoring and ransomware alerts. Respond: Isolate compromised environments. Recover: Restore clean records and independently reconcile them. |
Cyber threat assessment; privileged access reviews; immutable-backup verification; recovery exercise; reconciliation sign-offs; remediation register. |
Prove that PIDM can establish a clean recovery point and resume essential processing without relying on compromised information. |
|
CBS-1.8 |
Validate Total Insured Deposits |
Member submissions; CBS-1.6–1.7; calculation rules; independent reviewers; CBS-1.10 and CBS-7. |
Trigger: Defective validation logic. Amplifier: Automated controls use the same flawed inputs or algorithms and fail to identify errors. |
Yes, conditional. Materially incorrect totals could cause erroneous assessments or missed deadlines; a failure to detect them could trigger an integrity breach. |
Prevent: Independently verified calculation specifications and controlled releases. Detect: Source-to-output reconciliation and anomaly checks. Respond: Suspend affected totals. Recover: Recalculate and approve corrected figures. |
Rule test results; independent calculation evidence; reconciliation reports; change approvals; corrected assessment records. |
Verify that correlated control failures are detected and inaccurate totals are prevented from entering premium assessment. |
|
CBS-1.9 |
Assess Member Bank Premium Classification |
Assessment inputs; approved classification criteria; specialist approvals; CBS-1.10; member bank liaison and CBS-7. |
Trigger: Compromised or defective data import. Amplifier: Automated classification spreads errors across several banks. |
Yes, conditional. Incorrect classifications could lead to material premium errors and missed obligations. |
Prevent: Authenticate inputs and require independent classification approval. Detect: Compare results with source evidence and investigate anomalies. Respond: Suspend affected classifications. Recover: Reassess and correct downstream premiums. |
Data lineage records; classification approval logs; anomaly reports; quality reviews; correction and member notification records. |
Establish whether compromised inputs can be identified and corrected before material premium obligations are issued. |
|
CBS-1.10 |
Calculate and Assess Deposit Insurance Premiums |
Validated totals; premium classifications; calculation engine; finance approvals; CBS-1.11 and CBS-8. |
Trigger: Failed software release. Amplifiers: Database schema incompatibility, ineffective rollback and limited alternative calculation capacity. |
Yes. A material assessment error, missed applicable deadline, or prolonged inability to process premiums could breach tolerance. |
Prevent: Independent calculation testing and rehearsed rollback. Detect: Parallel-run comparisons and financial reconciliations. Respond: Freeze erroneous assessments and invoke controlled alternative calculation. Recover: Reconcile and approve all results. |
Change approvals; parallel-run reports; rollback tests; manual calculation exercise; financial reconciliation; deadline compliance evidence. |
Demonstrate accurate premium assessment and timely completion despite loss of the primary calculation capability. |
|
CBS-1.11 |
Administer Premium Collection and Reconciliation |
Member banks; banking and payment service providers; payment records; finance ledger; CBS-1.10, CBS-1.12 and CBS-8. |
Trigger: Banking interface outage. Amplifier: Fraudulent payment instructions or compromised account information undermine confidence in alternate processing. |
Yes, conditional. Unreconciled receipts, incorrect payment directions, or missed collection obligations could breach financial integrity or statutory requirements. |
Prevent: Verify bank details independently and segregate duties. Detect: Exception-based reconciliation and fraud alerts. Respond: Suspend suspect instructions and obtain authenticated bank confirmations. Recover: Reconcile every affected receipt. |
Bank confirmation records; payment control tests; reconciliation reports; fraud response exercise; alternate statement access test. |
Verify that collection status remains trustworthy and no fraudulent or duplicate processing occurs during interface failure. |
|
CBS-1.12 |
Monitor Member Bank Compliance with Deposit Insurance Requirements |
Membership, submission, premium and disclosure records; compliance data feeds; case management; CBS-7 and CBS-10. |
Trigger: Silent reporting feed failure. Amplifier: Dashboard health indicators remain normal despite missing records. |
Yes, conditional. Material breaches may remain undetected until statutory deadlines or service integrity conditions are exceeded. |
Prevent: Data completeness controls and independent compliance records. Detect: Feed heartbeat, reconciliation and overdue-case alerts. Respond: Conduct manual exception reviews. Recover: Rebuild missing cases and verify corrective actions. |
Feed monitoring tests; source-to-dashboard reconciliations; compliance exception reports; manual review exercise; case reconstruction records. |
Demonstrate that PIDM detects missing compliance information and maintains oversight when the primary dashboard is misleading. |
|
CBS-1.13 |
Administer Deposit Insurance Disclosure Requirements |
Coverage rules and records; approved disclosure templates; member bank publication channels; CBS-1.14 and CBS-9. |
Trigger: Failed content update. Amplifier: Cached or replicated outdated templates remain in circulation. |
Yes. Materially inaccurate protection disclosures could immediately breach the integrity condition, particularly during distress. |
Prevent: Controlled templates and approval workflow. Detect: Periodic publication verification. Respond: Issue authenticated correction instructions and withdraw outdated materials. Recover: Confirm correction across affected channels. |
Template approvals; publication inventory; verification results; correction exercise; member bank acknowledgements. |
Verify the ability to identify, withdraw and correct widespread inaccurate disclosures before material depositor harm develops. |
|
CBS-1.14 |
Provide Deposit Insurance Protection Information |
Verified coverage records; website and enquiry channels; communications personnel; telecommunications providers; CBS-9. |
Triggers: Denial-of-service attack and telecom failure. Amplifier: Demand surge overwhelms remaining channels. |
Yes. Loss of all effective authoritative channels during distress could exceed the four-hour threshold; misinformation could breach integrity conditions earlier. |
Prevent: Channel diversity, denial-of-service protection and approved crisis content. Detect: Availability and enquiry-capacity monitoring. Respond: Activate alternate channels and prioritised messaging. Recover: Restore channels and verify published content. |
Communication capacity tests; denial-of-service exercise; alternate-channel activation logs; message approvals; enquiry metrics. |
Demonstrate continued access to verified protection information during concurrent channel failures and elevated demand. |
|
CBS-1.15 |
Manage Deposit Insurance Administrative Exceptions |
Error reports from CBS-1.3–1.14; case management; legal and finance specialists; authorised escalation and correction processes. |
Amplifier: A case-management outage prevents identification of duplicate, overdue, or unresolved exceptions after an initial processing defect. |
Yes, conditional. Material unresolved errors could propagate into authoritative decisions or cause capacity and deadline breaches. |
Prevent: Controlled case ownership and severity rules. Detect: Independent backlog and exception reconciliation. Respond: Activate an alternate case register and prioritise high-harm cases. Recover: Reconcile all decisions into the primary system. |
Case management procedures; backlog dashboards; alternate-register exercise; approval trails; post-restoration reconciliation. |
Demonstrate that critical exceptions remain traceable and are resolved before inaccurate outputs spread. |
|
CBS-1.16 |
Monitor Deposit Insurance Service Performance |
Operational data feeds; system telemetry; incident records; service owner; time services; CBS-1.17. |
Triggers: Failed monitoring change and time synchronisation failure. Amplifier: Missing alerts delay escalation across several processes. |
Yes, conditional. An undetected outage may exceed duration or capacity thresholds before response begins. |
Prevent: Independent monitoring paths and controlled monitoring changes. Detect: Alert heartbeat and time-source checks. Respond: Activate manual service reporting. Recover: Restore telemetry and reconstruct the incident timeline. |
Monitoring coverage assessment; alert tests; time synchronisation reports; manual reporting exercise; incident timeline validation. |
Confirm that service deterioration is detected and escalated even when primary monitoring and event timestamps are unreliable. |
|
CBS-1.17 |
Manage Deposit Insurance Service Disruptions |
CBS owner; crisis and BCM teams; cyber responders; alternate facilities; emergency communications; member banks; CBS-2, CBS-5, CBS-9 and CBS-10. |
Amplifiers: Cyberattack disables response tools; communications and facilities failures prevent coordination and recovery access. |
Yes. Delayed continuity activation could allow several processes to exceed duration, capacity or cross-CBS tolerance conditions. |
Prevent: Delegated authority, alternate command arrangements and offline plans. Detect: Multi-source incident reporting. Respond: Use out-of-band communications and prioritise essential service outcomes. Recover: Coordinate verified restoration across functions. |
Crisis plans; delegation register; alternate-site and communication tests; integrated cyber-crisis exercise; management decision log. |
Verify that decision-making and coordinated continuity remain effective when normal systems, premises and communications are unavailable together. |
|
CBS-1.18 |
Restore and Reconcile Deposit Insurance Administration |
Backup infrastructure; transaction logs; IT recovery personnel; business process owners; finance; CBS-1.7, CBS-1.11 and downstream services. |
Trigger: Failed replication. Amplifiers: Compromised backups, missing transaction logs and pressure to declare recovery before validation. |
Yes. Material unreconciled data would breach the integrity condition; extended verification could also exceed the duration threshold. |
Prevent: Independent recovery architecture and protected transaction records. Detect: Automated and manual reconciliation. Respond: Restrict processing until integrity is confirmed. Recover: Restore clean data, clear exceptions, and approve service resumption. |
Backup integrity results; failover reports; transaction reconciliation; recovery acceptance criteria; business sign-off; outstanding-item register. |
Demonstrate that restoration achieves accurate end-to-end service delivery, not merely application availability. |
For every scenario, management should evaluate the actual disruption timeline, affected member banks and processes, minimum service capacity, data integrity, decision quality, effectiveness of alternative arrangements, cross-CBS consequences, and the time required for verified restoration.
A test should also identify whether an apparent success depends on an unrealistic assumption—for example, that specialist staff, network access, a third-party provider and clean backups will all remain available during a compound incident.
A scenario is not successfully managed merely because the primary application is restored. PIDM must demonstrate that essential protection administration continues or resumes without unacceptable harm.
Bank Negara Malaysia issued its Operational Resilience Discussion Paper on 19 December 2025.
The document sets out BNM's emerging direction and invites feedback on how to incorporate operational resilience concepts into Malaysia's regulatory framework. It is a discussion paper, not itself a final operational resilience policy document.
Its defined population of financial institutions includes banking and Islamic banking institutions, insurers, takaful operators, prescribed development financial institutions, operators of designated payment systems and specified electronic money issuers.
PIDM is not expressly included in that definition. Accordingly, this chapter uses the paper as a relevant Malaysian supervisory benchmark for PIDM's implementation methodology; it does not assume that every proposal in the paper is directly binding on PIDM.
For a financial institution within the scope of BNM's existing policies, applicable obligations must also be determined from the relevant final policy documents and the institution's regulatory status.
The following table separates concepts and examples actually discussed in BNM's paper from the implementation approach recommended for PIDM.
|
BNM Discussion Paper content |
Relevance to scenario identification |
PIDM implementation recommendation |
|
Critical service continuity: Paragraphs 3.2–3.3 discuss the ability of critical operations or services to withstand severe but plausible disruptions and preserve essential outcomes. |
Scenarios should test whether the service remains deliverable, not simply whether a department or system recovers. |
Define essential CBS-1 outcomes for normal conditions and member institution distress; measure them throughout each test. |
|
Internal and external dependency mapping: Paragraph 3.3 identifies dependencies across people, processes, data, technology, facilities and external providers. |
Failure pathways should reflect actual interconnections and concentration points. |
Link each scenario to PIDM's validated CBS-1 dependency map and identify affected downstream services. |
|
Third-party resilience: The paper discusses third-party outages, concentration, substitutability and alternative arrangements. |
An internally successful recovery may fail if the same external provider supports production and alternatives. |
Test the loss of critical information exchange, hosting, telecommunications or banking arrangements where such dependencies are confirmed. |
|
Disruption tolerances: Paragraph 3.3 discusses boundaries for acceptable duration, customer or market harm and minimum operating levels. |
Tests should measure disruption consequences against defined service-level boundaries. |
Assess each scenario against approved duration, integrity, capacity, statutory and cross-service conditions. |
|
Severe but plausible testing: Paragraphs 2.9 and 3.3 emphasise scenarios severe enough to reveal deficiencies, including concurrent and multilayered failures. |
Testing isolated system failures alone may conceal common-cause weaknesses. |
Combine cyber, personnel, communications, information integrity and recovery failures in selected end-to-end tests. |
|
Technology and cyber risk: The paper discusses ransomware, destructive malware, compromised information, technology outages and shared infrastructure. |
Cyber incidents can impair information trustworthiness, the recovery environment, and system availability. |
Test compromised authoritative records, inaccessible clean backups, failed access management and simultaneous channel outages. |
|
Governance and learning: The paper emphasises board and senior management ownership, cross-functional decisions and continuous improvement. |
Scenario outcomes should inform decisions and not remain confined to exercise teams. |
Require management review of breaches, accountable remediation, retesting and reporting of unresolved material vulnerabilities. |
Important distinction: These entries summarise themes and considerations discussed by BNM.
The specific PIDM test designs, thresholds, evidence records and remediation actions in the third column are recommendations developed for this guide, not requirements quoted from the Discussion Paper.
BNM's paper describes cyber incidents, technology failures, third-party outages, compromised information assets and power outages as causes of operational disruption.
It also discusses concentration in telecommunications, cloud and other shared infrastructure, alongside the effects of floods and other physical events.
Its discussion of past incidents includes an IT migration failure, disruption to European payment and settlement infrastructure, a major power blackout, Malaysian banking and payment service outages, a failed disaster recovery test and a ransomware incident involving weak cybersecurity controls.
These are examples cited in the paper, not descriptions of incidents at PIDM.
For CBS-1, these examples support considering compound scenarios such as a failed technology change during a reporting cycle, ransomware affecting deposit records and recovery arrangements, or telecommunications failure during heightened depositor enquiries.
The precise PIDM scenarios in Tables 1 and 2 are adaptations developed for this chapter, not scenarios prescribed by BNM.
The Discussion Paper explains that BNM's existing Business Continuity Management, Risk Management in Technology and outsourcing requirements already address elements of continuity planning, technology robustness, dependency identification and third-party controls for institutions to which those policies apply.
It explores whether operational resilience should be articulated more explicitly within the existing framework or through a separate construct.
PIDM should therefore distinguish three matters in its implementation records: the legal and statutory requirements that actually apply to PIDM; the supervisory concepts drawn from BNM's Discussion Paper; and the additional practices adopted voluntarily through PIDM's operational resilience methodology.
This distinction will make the resulting documentation clearer for management, internal audit and any supervisory or independent review.
Identifying scenarios is only the first step. PIDM should select a manageable set of integrated exercises that collectively challenge the full service, rather than conduct 18 isolated technology recovery tests.
|
Integrated exercise |
Combined scenarios |
End-to-end outcome to demonstrate |
|
Exercise A — Coverage integrity crisis |
CBS-1.2, CBS-1.3, CBS-1.4, CBS-1.13 and CBS-1.14 |
Detect incorrect coverage information, stop its propagation, correct affected records and provide verified stakeholder information. |
|
Exercise B — Deposit information compromise |
CBS-1.5, CBS-1.6, CBS-1.7 and CBS-1.8 |
Maintain or restore trustworthy deposit information through alternate submissions, clean recovery and independent validation. |
|
Exercise C — Premium cycle disruption |
CBS-1.9, CBS-1.10, CBS-1.11, CBS-1.12 and CBS-1.15 |
Complete essential assessments and reconciliations without material errors or missed applicable obligations. |
|
Exercise D — Compound crisis and recovery |
CBS-1.1, CBS-1.14, CBS-1.16, CBS-1.17 and CBS-1.18, with dependencies from the other processes |
Maintain command, confirm authoritative membership information, communicate with stakeholders and restore the service safely during concurrent failures. |
The grouping is illustrative. Individual Sub-CBS scenarios should remain available for targeted control tests, while integrated exercises should establish whether CBS-1 can withstand cascading disruption.
Each approved scenario should contain a documented scenario narrative, affected CBS and Sub-CBS, disruption triggers, assumptions, confirmed dependencies, participating teams, expected escalation decisions and the impact tolerance conditions being tested.
The specification should also identify whether the exercise is a tabletop discussion, technical simulation, controlled failover, data recovery test, third-party exercise or a combination of methods.
A tabletop exercise can demonstrate decision-making but cannot, by itself, prove that a backup is recoverable or that an alternate information exchange channel can handle the required workload.
This sequence tests incident classification, cyber containment, backup trustworthiness, alternative submissions, information integrity, prioritisation, management decisions and the criteria for declaring CBS-1 restored.
PIDM should record the actual sequence of events and decisions during each exercise.
Evidence should include system and service timestamps, operational volumes, rejected or corrupted records, incident escalation records, alternative processing outputs, communication approvals, recovery results and reconciliation sign-offs.
Management should specifically determine whether the service remained within tolerance, which assumptions failed, whether controls operated as designed and whether dependencies caused disruption to spread further than expected.
A test result should distinguish between demonstrated capability and capability that was merely discussed or assumed.
PIDM should establish a controlled scenario register that links each approved scenario to its originating Sub-CBS, relevant dependency chains, impact tolerance conditions, test owner, execution date, results, and remediation actions.
The CBS owner should be accountable for the end-to-end service outcome.
Operational resilience and BCM functions should coordinate testing, while business, technology, cybersecurity, operational risk, communications and relevant third-party representatives should validate their respective capabilities.
Senior management should review scenarios that could cause significant depositor harm, material statutory consequences, information integrity failure or cascading disruption across multiple critical business services. Board or Board Risk Committee reporting should follow PIDM's actual governance arrangements.
For each material test finding, the responsible owner should document the weakness, its effect on CBS-1, interim risk treatment, permanent remediation, target completion date and required retest.
Decisions to accept residual risk should be made through authorised governance and should not be used to redefine an impact tolerance solely to accommodate inadequate capabilities.
Severe but Plausible Scenarios are essential to establishing whether PIDM can maintain CBS-1: Deposit Insurance Protection Administration within its approved Impact Tolerance when significant disruption occurs.
Identifying scenarios at the Sub-CBS level provides a detailed understanding of where disruption may originate, how it affects individual processes and how consequences can propagate through the end-to-end service.
The 18 proposed scenarios collectively challenge membership administration, coverage integrity, deposit information, premium processing, compliance, communication, incident management and restoration.
Integrating cyber and ICT risks into each scenario is necessary because technology failures can initiate disruption, amplify operational weaknesses, compromise authoritative information and undermine recovery arrangements.
A credible resilience assessment must therefore test service outcomes, not merely the restoration of individual applications.
The proposed proactive actions and associated evidence establish a basis for demonstrating preparedness through verified controls, exercised alternatives, documented decisions and tested recovery capabilities.
PIDM should validate them against its actual operating environment before treating them as established arrangements.
The scenario catalogue provides the foundation for the next implementation activity: conducting end-to-end Operational Resilience scenario testing.
Assess results against approved Impact Tolerances and use them to identify vulnerabilities, prioritise remediation and investment, strengthen risk treatment, and support continuous resilience improvement.
| eBook 3: Starting Your OR Implementation |
||||
| CBS-1 Deposit Insurance Protection Administration | ||||
| CBS-1 DP | CBS-1 MII | CBS-1 ITo | CBS-1 SbPS | CBS-1 ST |
To learn more about the course and schedule, click the buttons below for the OR-300 Operational Resilience Implementer course and the OR-5000 Operational Resilience Expert Implementer course.
|
If you have any questions, click to contact us. |
||
|
|