Scenario Testing enables PIDM to establish whether CBS-1: Deposit Insurance Protection Administration can continue delivering its essential outcomes during severe but plausible disruption.
It provides evidence of resilience capability by challenging the assumptions, interconnections and recovery arrangements on which the service depends.
Testing must examine the end-to-end service rather than only establishing that individual applications, business continuity plans, or disaster recovery arrangements function as designed.
A technology platform may recover successfully while deposit insurance administration remains impaired because authoritative records are inconsistent, member bank information is unavailable, essential personnel cannot make decisions or outstanding transactions have not been reconciled.
The severe but plausible scenarios identified in the preceding chapter provide the starting point for testing. The 18 Sub-Critical Business Services (Sub-CBS) establish where disruption can originate, how it may propagate and which operational capabilities must be demonstrated.
PIDM's approved Impact Tolerance must provide the boundary against which test results are assessed.
Cyber and ICT risks must be incorporated into the same tests because ransomware, data corruption, identity failures, infrastructure outages and compromised recovery environments can affect multiple Sub-CBS processes simultaneously.
The programme proposed in this chapter combines targeted control tests with integrated service exercises. Its purpose is not to confirm that existing arrangements will succeed, but to determine what actually happens when important assumptions fail and identify improvements needed to prevent unacceptable harm.
Implementation qualification: PIDM's actual systems, third-party providers, approved tolerance and control effectiveness have not been verified. The tests and controls below are proposals for PIDM to adapt, validate and approve.
PIDM should define the minimum outcomes that CBS-1 must deliver during disruption:
These outcomes should be assessed collectively. An exercise should not be declared successful merely because one participating function meets its own recovery objective.
The preceding chapter proposed illustrative thresholds for scenario design:
|
Tolerance dimension |
Provisional assessment boundary |
|
Normal operating conditions |
Maximum 24 hours of disruption to essential administration. |
|
Heightened financial stress |
Maximum four hours for essential protection information and administrative capabilities. |
|
Information integrity |
No knowingly released materially incorrect authoritative protection decisions or coverage information. |
|
Minimum capacity |
At least 50% of essential workload, subject to validation. |
|
Information currency |
Essential approved membership and coverage changes available within four hours during heightened stress, subject to validation. |
|
Statutory obligations |
No material breach of applicable requirements or deadlines. |
|
Connected services |
No resulting breach of another CBS's approved tolerance. |
|
Restoration |
Verify and reconcile essential records and transactions before unrestricted resumption. |
These figures are not confirmed PIDM thresholds or BNM requirements. They are provisional assumptions for designing challenging exercises. Actual pass/fail decisions must use PIDM's formally approved tolerance, once established.
A test breaches the tolerance if it exceeds any applicable boundary.
Meeting a recovery-time target does not compensate for releasing materially incorrect protection information.
|
Testing method |
Appropriate use |
Limitation |
|
Walk-through or tabletop |
Tests roles, decisions, escalation and alternative procedures. |
Does not prove technical performance or processing capacity. |
|
Technical simulation |
Tests controlled system, network, security or application failure. |
May not demonstrate full business consequences unless linked to operational participants. |
|
Data integrity and reconciliation test |
Verifies correctness and completeness of restored or transformed information. |
Must use representative datasets and independently verified expected results. |
|
Capacity or stress test |
Establishes throughput and backlog behaviour under adverse conditions. |
Must reflect realistic workload, dependencies and constraints. |
|
Third-party disruption exercise |
Tests external coordination and alternatives. |
Requires participation or credible independently evidenced assumptions. |
|
Integrated end-to-end exercise |
Tests multiple Sub-CBS processes, decision-making and CBS outcomes together. |
Requires careful control, realistic injects and comprehensive evidence collection. |
Live disruption testing should occur only with explicit authorisation, safeguards and defined abort criteria.
Production data must not be deliberately corrupted or exposed merely to make a test more realistic.
Each test below is linked to the severe but plausible scenario identified in the preceding chapter.
The proposed methods are selected based on what must be demonstrated: decision-making, operational throughput, information integrity, external coordination, or technical recovery.
Organise the tests into integrated exercises rather than executing them as 18 disconnected activities. The interconnections column identifies the principal relationships to be challenged.
|
Sub-CBS Code |
Name of Sub-CBS |
Severe but Plausible Scenario |
Recommended Scenario Test |
Testing Method |
Scenario Testing Objective |
Key Scenario Injects / Disruption Conditions |
Interconnections and Interdependencies Tested |
|
CBS-1.1 |
Administer Member Bank Participation |
Conflicting membership status during an urgent institutional change. |
T01 — Membership status verification under disruption. Reconstruct an authoritative membership decision while the normal register is unavailable. |
Integrated legal–business walk-through with controlled record-recovery simulation; verifies decision authority and record consistency, not just application availability. |
Confirm the correct status and effective date, prevent unverified downstream updates, and restore a consistent register within the applicable tolerance. |
Register outage; conflicting status notices; unavailable approver; downstream request for immediate confirmation. |
Authoritative institutional notices; legal approvals; membership register; CBS-1.5, CBS-1.9, CBS-1.12 and proposed CBS-7 membership obligations. |
|
CBS-1.2 |
Maintain Deposit Insurance Coverage Framework |
Compromised coverage rules distributed across administrative processes. |
T02 — Coverage rule integrity challenge. Introduce a controlled, incorrect rule version into a non-production test environment and trace its potential distribution. |
Data integrity simulation combined with legal and operational decision testing; tests whether a technically available repository remains trustworthy. |
Detect the discrepancy before a material decision is issued, withdraw suspect guidance and revalidate affected outputs. |
Altered rule; apparently valid approval metadata; conflicting archived version; urgent request for product determination. |
Legal interpretation; controlled rules repository; CBS-1.3, CBS-1.4, CBS-1.13, CBS-1.14 and reimbursement-related information. |
|
CBS-1.3 |
Assess Deposit Product Insurability |
Surge in complex assessments during specialist unavailability. |
T03 — Product eligibility surge and deputisation test. Process representative urgent assessments with key specialists absent. |
Capacity simulation and supervised alternative-workflow exercise; demonstrates whether personnel substitution maintains decision quality. |
Complete the minimum required assessment workload without unauthorised or materially incorrect classifications. |
Simultaneous urgent submissions; unavailable legal specialist; inaccessible prior decisions; conflicting product documents. |
Member bank submissions; legal and product specialists; CBS-1.2, CBS-1.4 and disclosure functions. |
|
CBS-1.4 |
Administer Deposit Product Coverage Records |
Silent corruption of authoritative product classifications. |
T04 — Coverage record corruption and rollback test. Detect, isolate and reverse altered classifications in a controlled dataset. |
Technical data integrity and reconciliation test; independently verifies record correctness rather than relying on system health indicators. |
Identify all affected records, prevent their publication and restore a verified authoritative version. |
Faulty migration; successful application health checks; replicated errors; incomplete initial reconciliation. |
Classification approvals; coverage database; backups; CBS-1.3, CBS-1.13, CBS-1.14 and CBS-2 reimbursement information. |
|
CBS-1.5 |
Administer Member Bank Deposit Information Requirements |
Inconsistent reporting specifications during a change. |
T05 — Reporting specification distribution exercise. Verify that affected banks receive one authoritative version through alternative channels. |
Third-party/member bank coordination exercise and document-control test; challenges an external hand-off. |
Correct the version discrepancy and enable compliant submissions before relevant deadlines are missed. |
Primary distribution outage; two conflicting specification versions; missing acknowledgements; approaching reporting deadline. |
Approved reporting requirements; member bank contacts; communications channels; CBS-1.6 and CBS-10 information coordination. |
|
CBS-1.6 |
Receive and Validate Deposit Insurance Information |
Submission gateway disruption during peak reporting. |
T06 — Peak-volume submission continuity test. Simulate gateway unavailability and process submissions through an authorised alternative. |
Network/API resilience and capacity test integrated with operational processing; measures actual accepted throughput and validation quality. |
Maintain the approved minimum workload, reject invalid files and clear the backlog within tolerance. |
Denial-of-service simulation; malformed files; multiple bank submissions; reduced alternate-channel capacity. |
Member bank interfaces; network providers; secure transfer; validation rules; CBS-1.5, CBS-1.7 and CBS-1.8. |
|
CBS-1.7 |
Maintain Insured Deposit Information and Records |
Ransomware compromises production records and accessible backups. |
T07 — Clean-data recovery under cyber compromise. Recover representative records from an independently verified recovery point. |
Cyber incident simulation plus isolated disaster recovery and data integrity test; challenges backup trustworthiness. |
Establish a clean recovery point, restore essential records and verify accuracy before processing resumes. |
Ransomware alert; compromised administrator account; suspect recent backup; incomplete transaction history. |
Identity management; data repository; isolated backups; cyber response; CBS-1.6, CBS-1.8, CBS-1.10 and CBS-2. |
|
CBS-1.8 |
Validate Total Insured Deposits |
Systematic miscalculation escapes correlated automated controls. |
T08 — Independent insured-deposit recalculation. Introduce controlled rule defects and compare results against independently calculated totals. |
Data integrity and reconciliation test; exposes common-mode errors in calculation and checking mechanisms. |
Detect material discrepancies before totals enter premium assessment and reprocess affected records accurately. |
Defective validation rule; apparently normal automated checks; inconsistent sample totals; assessment deadline pressure. |
Source submissions; validated repository; independent reviewers; CBS-1.6, CBS-1.7 and CBS-1.10. |
|
CBS-1.9 |
Assess Member Bank Premium Classification |
Compromised assessment input produces incorrect classifications. |
T09 — Premium classification challenge. Test detection and reassessment of manipulated input data. |
Controlled fraud/data-integrity simulation with business approval walk-through; tests judgement and segregation of duties. |
Prevent incorrect classifications from becoming authoritative and correct affected downstream calculations. |
Altered assessment input; anomalous classification; absent reviewer; bank dispute. |
Approved classification criteria; specialist approvals; member bank information; CBS-1.10 and CBS-1.12. |
|
CBS-1.10 |
Calculate and Assess Deposit Insurance Premiums |
Failed calculation release immediately before a deadline. |
T10 — Premium cycle continuity exercise. Execute rollback or alternative calculations against representative assessment volumes. |
Integrated business–technology simulation and parallel calculation test; demonstrates actual processing capability under deadline pressure. |
Produce independently verified assessments and meet applicable obligations without material errors. |
Faulty release; unsuccessful initial rollback; reduced processing capacity; approaching deadline. |
Validated totals; classifications; calculation engine; finance approval; CBS-1.8, CBS-1.9 and CBS-1.11. |
|
CBS-1.11 |
Administer Premium Collection and Reconciliation |
Payment confirmation outage and suspected fraudulent instructions. |
T11 — Premium receipt verification and reconciliation test. Confirm payment status through authenticated alternatives. |
Banking-provider coordination and financial reconciliation exercise; challenges both external availability and fraud controls. |
Prevent incorrect payment instructions, establish reliable receipt status and reconcile all affected transactions. |
Missing confirmations; altered payment details; unmatched receipts; duplicate payment notification. |
Banking provider; member banks; finance ledger; payment controls; CBS-1.10, CBS-1.12 and CBS-8. |
|
CBS-1.12 |
Monitor Member Bank Compliance with Deposit Insurance Requirements |
Silent compliance reporting feed failure. |
T12 — Compliance monitoring blind-spot test. Interrupt a controlled feed while dashboards appear operational. |
Simulate a monitoring failure and conduct a manual compliance review; test detection of missing information rather than obvious system failure. |
Identify incomplete monitoring, reconstruct outstanding cases and escalate material breaches before deadlines. |
Missing feed; normal-looking dashboard; overdue disclosure case; incomplete premium status. |
Reporting interfaces; source records; compliance personnel; CBS-1.1, CBS-1.11, CBS-1.13 and CBS-7. |
|
CBS-1.13 |
Administer Deposit Insurance Disclosure Requirements |
Incorrect protection disclosures distributed widely. |
T13 — Disclosure withdrawal and correction exercise. Trace and correct an outdated template across participating channels. |
Publication integrity test and member bank coordination simulation; tests external correction capability. |
Identify affected publications, stop inaccurate disclosure and confirm correction before material depositor harm. |
Outdated template; cached content; multiple affected banks; rising complaints. |
Coverage framework; disclosure templates; member bank channels; CBS-1.2, CBS-1.4, CBS-1.14 and CBS-9. |
|
CBS-1.14 |
Provide Deposit Insurance Protection Information |
Website and telecommunications failure during member bank distress. |
T14 — Depositor communication surge exercise. Activate alternative verified information channels under simultaneous failures. |
Controlled communications capacity test and crisis simulation; measures service accessibility and message accuracy. |
Maintain at least one effective authoritative channel and meet the approved heightened-stress boundary. |
Denial-of-service simulation; telephony outage; enquiry surge; misleading external information. |
Approved coverage information; website; enquiry personnel; telecommunications; CBS-1.13, CBS-1.17 and CBS-9. |
|
CBS-1.15 |
Manage Deposit Insurance Administrative Exceptions |
Processing errors generate a critical backlog while case management fails. |
T15 — Exception surge and alternative case-control test. Track and resolve priority cases without the normal platform. |
Operational stress test with alternative case register and reconciliation; measures traceability and backlog clearance. |
Prevent material errors from propagating, retain decision evidence and reconcile all cases after recovery. |
Sudden case surge; unavailable case platform; duplicate cases; urgent premium and coverage decisions. |
Business and legal specialists; case records; CBS-1.3–1.14; recovery and approval processes. |
|
CBS-1.16 |
Monitor Deposit Insurance Service Performance |
Monitoring failure masks service deterioration. |
T16 — Monitoring and escalation challenge. Disable selected test alerts and introduce inconsistent timestamps. |
Controlled monitoring simulation with incident timeline reconstruction; demonstrates independent detection capability. |
Detect degradation, identify affected processes and escalate before tolerance thresholds are crossed. |
Missing alerts; clock drift; growing backlog; delayed incident acknowledgement. |
Operational dashboards; time services; service owners; security monitoring; CBS-1.17 and all affected Sub-CBS. |
|
CBS-1.17 |
Manage Deposit Insurance Service Disruptions |
Cyber incident and facilities outage impair crisis coordination. |
T17 — Compound CBS-1 crisis exercise. Operate an alternate command structure with degraded systems, premises and communications. |
Integrated crisis management and end-to-end CBS simulation; tests simultaneous operational and cyber decisions. |
Activate continuity, prioritise essential outcomes, coordinate stakeholders and contain disruption within tolerance. |
Cyber compromise; inaccessible primary location; unavailable decision-maker; communications outage; cross-CBS escalation. |
Crisis team; BCM; cyber response; alternate facilities; member banks; CBS-2, CBS-5, CBS-9 and CBS-10. |
|
CBS-1.18 |
Restore and Reconcile Deposit Insurance Administration |
Applications recover, but records and transactions remain incomplete. |
T18 — Verified service restoration test. Reconcile restored information and obtain business acceptance before unrestricted processing. |
Technical failover, data reconciliation and operational resumption test; proves end-to-end restoration rather than application recovery alone. |
Demonstrate complete, accurate records, controlled backlog clearance and authorised return to service within tolerance. |
Successful technical failover; missing updates; inconsistent premium records; pressure for early reopening. |
Backups; transaction logs; technology recovery; finance and business owners; CBS-1.7, CBS-1.11 and downstream services. |
Table 2 specifies the results PIDM should seek from each test. It also distinguishes evidence collected during testing from evidence demonstrating that a subsequent risk management improvement has actually been implemented.
The expected outcomes are proposed success criteria.
Record actual test results separately, including failures, partial successes, and assumptions that could not be verified.
|
Sub-CBS Code |
Name of Sub-CBS |
Cyber and ICT Risk Linkage |
Impact Tolerance Boundary Tested |
Expected Resilience Outcome |
Evidence to be Collected |
Proactive Risk Management Action |
Evidence of Proactive Risk Management |
|
CBS-1.1 |
Administer Member Bank Participation |
A database outage is the trigger; identity failure and inconsistent replicas amplify uncertainty about authoritative status. |
No material membership error; four-hour information currency threshold during stress; applicable service duration. |
Membership status is independently verified; suspect updates are withheld; all affected downstream records are reconciled. |
Status notices; decision timestamps; approval records; register comparisons; downstream correction log. |
Establish a controlled alternate status-verification procedure, deputy approval authority and independent register reconciliation. |
Approved procedure; delegated authority register; completed verification exercise; signed reconciliation report. |
|
CBS-1.2 |
Maintain Deposit Insurance Coverage Framework |
Privileged access compromise or failed publication initiates incorrect rule distribution. |
Zero knowingly released material coverage errors; applicable duration and information currency conditions. |
Detect and quarantine incorrect rules before authoritative use; review affected decisions. |
Repository audit trail; integrity alerts; affected-document inventory; legal decision log; correction timestamps. |
Introduce independent rule-version verification, dual publication approval and a rapid withdrawal mechanism. |
Approved rule controls; access review; integrity test; withdrawal exercise; legal sign-off. |
|
CBS-1.3 |
Assess Deposit Product Insurability |
Workflow deployment failure amplifies specialist unavailability; compromised submissions could introduce incorrect evidence. |
Minimum essential processing capacity; no material classification errors; applicable deadlines. |
Deputies process urgent cases using verified rules while unresolved cases remain appropriately controlled. |
Case throughput; backlog age; assessment decisions; quality review; staffing and escalation records. |
Cross-train deputies, preserve accessible approved precedents and establish a controlled offline assessment workflow. |
Competency records; deputisation approval; offline exercise; assessment quality assurance results. |
|
CBS-1.4 |
Administer Deposit Product Coverage Records |
Failed migration corrupts data; replication may distribute the corruption to backups and downstream repositories. |
Zero material coverage errors; recovery completeness; applicable duration. |
All altered records are identified, affected outputs are contained, and a verified record set is restored. |
Before-and-after datasets; discrepancy counts; migration logs; rollback timing; reconciliation sign-offs. |
Implement pre-release integrity baselines, independently protected record versions and mandatory post-change reconciliation. |
Migration control standard; integrity reports; protected-backup test; approved release and reconciliation records. |
|
CBS-1.5 |
Administer Member Bank Deposit Information Requirements |
Communications failure initiates inconsistent distribution; outdated document caches prolong the problem. |
Information availability; affected member bank scope; statutory deadlines; 24-hour normal disruption assumption. |
All affected banks receive one verified specification and can submit compliant information. |
Version comparison; delivery timestamps; bank acknowledgements; rejection rates; alternate-channel records. |
Maintain authenticated alternative distribution, a single authoritative specification register and confirmation procedures. |
Approved distribution protocol; version register; alternate-channel test; acknowledgement evidence. |
|
CBS-1.6 |
Receive and Validate Deposit Insurance Information |
Denial-of-service attack is the trigger; malformed files, network congestion, and capacity exhaustion amplify it. |
Minimum capacity; submission latency; applicable deadlines; information integrity; 24-hour or four-hour duration as applicable. |
Essential submissions continue through verified alternatives; reject invalid files; clear the backlog. |
Network telemetry; accepted/rejected volumes; validation results; throughput measurements; backlog timeline. |
Establish protected submission channels, tested alternative transfer capacity and priority-based processing. |
Security assessment; capacity report; alternate-channel exercise; validation control results; remediation closure. |
|
CBS-1.7 |
Maintain Insured Deposit Information and Records |
Ransomware is the trigger; compromised credentials and shared backup dependencies threaten recovery. |
Zero material data integrity errors; service duration; recovery completeness; connected CBS tolerances. |
Restore clean records from a verified recovery point without reintroducing compromise; business owners approve their use. |
Cyber logs; recovery-point verification; restore timing; record-level reconciliation; business acceptance. |
Segregate backup access, protect immutable recovery copies and test clean-room restoration with independent data verification. |
Backup architecture review; privileged access testing; isolated recovery report; reconciliation and approval records. |
|
CBS-1.8 |
Validate Total Insured Deposits |
Defective calculation logic initiates errors; correlated automated checks conceal them. |
Zero material incorrect totals used in authoritative decisions; applicable assessment deadlines. |
Independent verification identifies errors before downstream use and confirms corrected totals. |
Calculation comparisons; exception rates; affected-bank counts; recalculation timing; reviewer sign-offs. |
Establish independently derived control totals, regression testing and mandatory review of anomalous results. |
Approved validation methodology; regression reports; independent calculations; control testing evidence. |
|
CBS-1.9 |
Assess Member Bank Premium Classification |
Compromised imports or unauthorised input changes can trigger misclassification; automation amplifies the scope. |
Material financial integrity; classification accuracy; applicable deadlines. |
Suspend suspect classifications, reassess them, and prevent them from contaminating premium calculations. |
Data lineage; input-change logs; classification differences; approval records; correction timeline. |
Authenticate assessment inputs, segregate preparation and approval, and monitor anomalous classification changes. |
Access reviews; approval matrix; anomaly reports; quality assurance and retest results. |
|
CBS-1.10 |
Calculate and Assess Deposit Insurance Premiums |
Failed software release initiates calculation failure; schema changes and ineffective rollback prolong disruption. |
No material premium misstatement; applicable statutory deadlines; minimum processing capacity and duration. |
Verified assessments are completed using a tested alternative or recovered platform without material errors. |
Change and rollback logs; parallel calculations; assessment volumes; deadline timestamps; reconciliation. |
Require representative pre-release testing, reversible changes and independently verified alternative calculations. |
Release approval; rollback exercise; parallel-run results; continuity test; finance sign-off. |
|
CBS-1.11 |
Administer Premium Collection and Reconciliation |
Banking interface outage triggers missing confirmations; fraudulent instructions threaten the integrity of workarounds. |
Financial integrity; reconciliation completeness; applicable collection deadlines. |
Authenticate and reconcile genuine receipts; reject suspicious instructions; prevent duplicate processing. |
Bank confirmations; payment exception records; fraud alerts; unmatched amounts; reconciliation timing. |
Implement independent payment-detail verification, alternate bank confirmation and controlled reconciliation procedures. |
Payment-control test; authenticated bank confirmation records; alternative-access exercise; signed reconciliation. |
|
CBS-1.12 |
Monitor Member Bank Compliance with Deposit Insurance Requirements |
Silent feed failure creates a monitoring blind spot; a functioning dashboard conceals incomplete information. |
No material missed obligation; compliance case completeness; applicable deadlines. |
Independent feeds detect missing feeds, and alternative monitoring keeps material cases visible. |
Feed completeness comparisons; alert timing; case reconstruction; overdue-case reports; escalation records. |
Introduce source-to-dashboard completeness controls, feed health alerts and manual monitoring procedures. |
Monitoring design approval; alert tests; reconciliation reports; manual exercise; compliance review sign-off. |
|
CBS-1.13 |
Administer Deposit Insurance Disclosure Requirements |
Failed content changes can initiate outdated disclosures; caching and external distribution amplify their reach. |
Zero knowingly released material coverage misinformation; affected depositor scope; correction time. |
Locate, withdraw, and correct incorrect materials across affected channels. |
Publication inventory; template versions; member bank acknowledgements; correction timestamps; complaint trends. |
Establish approved master content, publication verification and a coordinated withdrawal-and-correction protocol. |
Content approvals; verification reports; withdrawal exercise; member acknowledgements; correction audit trail. |
|
CBS-1.14 |
Provide Deposit Insurance Protection Information |
Denial-of-service attacks and telecommunications failures can trigger channel loss; demand surges can exhaust alternatives. |
Four-hour heightened-stress duration; authoritative channel availability; message integrity; affected stakeholder scope. |
At least one effective verified information channel remains available, and communications are consistent. |
Channel availability; enquiry volumes; activation time; message approvals; unanswered demand; stakeholder feedback. |
Diversify communications, preapprove crisis messages, test surge capacity and maintain alternate channel activation authority. |
Capacity test; communications exercise; alternative-channel test; approved messages; management review. |
|
CBS-1.15 |
Manage Deposit Insurance Administrative Exceptions |
Case management outage amplifies a processing defect by removing normal tracking and escalation. |
Contain material error; minimum capacity; critical backlog and deadline limits. |
Priority exceptions remain traceable, receive authorised decisions and are reconciled after restoration. |
Case counts; severity classification; backlog age; decision logs; duplicate and missing-case checks. |
Establish a protected alternative register, severity-based triage and independent case reconciliation. |
Approved alternative procedure; exercise results; backlog reports; reconciliation sign-offs; corrective action records. |
|
CBS-1.16 |
Monitor Deposit Insurance Service Performance |
Failed monitoring change and time synchronisation error obscure incidents and compromise event sequencing. |
Detection and escalation before duration or capacity thresholds are exceeded. |
Independent monitoring identifies deterioration, and you can reconstruct an accurate incident timeline. |
Alert logs; independent measurements; time offsets; detection-to-escalation interval; reconstructed timeline. |
Deploy independent service-outcome indicators, monitor health checks, and maintain resilient time synchronisation. |
Monitoring coverage review; alert and clock tests; manual reporting exercise; management dashboard evidence. |
|
CBS-1.17 |
Manage Deposit Insurance Service Disruptions |
Cyber compromise, unavailable facilities and failed communications jointly impair incident command. |
Four-hour heightened-stress or 24-hour normal duration; minimum capacity; connected CBS tolerances. |
Alternate command activates, essential activities are prioritised and coordinated decisions limit cascading harm. |
Activation times; attendance and delegation; decision logs; communications records; service measures; cross-CBS impact assessment. |
Establish out-of-band communications, alternate command facilities, delegated authority and integrated cyber-crisis procedures. |
Crisis exercise; communication tests; delegation register; alternate-site test; approved remediation. |
|
CBS-1.18 |
Restore and Reconcile Deposit Insurance Administration |
Failed replication produces incomplete restored records; pressure to reopen early amplifies integrity risk. |
Zero material unreconciled authoritative errors; recovery completeness; applicable duration. |
Service resumes only after essential records, transactions and backlogs are verified and authorised. |
Restore timestamps; missing-transaction counts; reconciliation results; outstanding exceptions; acceptance decisions. |
Introduce business-led recovery acceptance criteria, independent reconciliation and formal restrictions on premature reopening. |
Recovery acceptance standard; disaster recovery test; reconciliation sign-offs; return-to-service approval; retest evidence. |
For each test, PIDM should record four distinct findings: whether the intended control operated, whether the end-to-end service remained within tolerance, whether the test was sufficiently realistic to support that conclusion, and whether unresolved vulnerabilities require further treatment.
Record a technically successful recovery with incomplete data reconciliation as an unsuccessful or incomplete service-level outcome.
Likewise, a tabletop discussion that assumes alternative capacity is available should not be treated as proof that the capacity exists.
The 18 tests should form a coordinated programme of four integrated exercises. Targeted tests establish whether specific controls work; integrated exercises establish whether those controls collectively preserve CBS-1.
|
Exercise |
Participating Sub-CBS |
Compound disruption |
Principal participants |
Service-level success criteria |
|
E1 — Coverage integrity and communication |
CBS-1.1–1.4, CBS-1.13–1.14 |
Conflicting membership information, corrupted coverage records and unavailable communication channels during member bank distress. |
CBS owner; legal; deposit insurance administration; communications; technology; cybersecurity; participating member bank representatives where feasible. |
Authoritative information is verified; material errors are contained; an effective communication channel remains available; applicable stress tolerance is met. |
|
E2 — Deposit information and cyber recovery |
CBS-1.5–1.8, CBS-1.16–1.18 |
Ransomware affects the information repository and accessible backups while the submission gateway is unavailable and monitoring is degraded. |
Deposit information owners; member bank liaison; technology recovery; cybersecurity; BCM; operational risk; recovery provider where applicable. |
Essential information is received or recovered, validated independently and processed at the approved minimum capacity without an integrity breach. |
|
E3 — Premium and compliance continuity |
CBS-1.8–1.12, CBS-1.15 |
A defective calculation release causes incorrect assessments, banking confirmations become unavailable, and compliance feeds fail before an applicable deadline. |
Premium administration; finance; compliance; technology; operational risk; banking service provider and member bank representatives where feasible. |
Correct premium obligations are established, receipts are reconciled, material exceptions remain controlled and applicable deadlines are met. |
|
E4 — Enterprise compound disruption |
All 18 Sub-CBS, with direct execution focused on CBS-1.14 and CBS-1.16–1.18 |
Cyber compromise, primary facilities loss, communication failure and incomplete recovery occur during heightened financial stress. |
CBS owner; crisis management; BCM; all critical business functions; technology; cybersecurity; legal; communications; operational risk; relevant external parties. |
Management demonstrates coordinated service delivery, safe prioritisation, effective cross-CBS escalation and verified restoration within approved tolerance. |
The exercises should progressively increase in complexity. E1–E3 can establish specific capabilities before E4 challenges their simultaneous operation.
Nevertheless, E4 should not assume that capabilities will succeed merely because they worked individually.
The CBS owner should direct business priorities, while participating teams execute their normal or alternative responsibilities.
Observers from operational resilience, operational risk or internal audit may provide independent challenge, subject to PIDM's governance arrangements. Third parties and member banks should participate when their cooperation is essential to validating a dependency; otherwise, the test report must disclose that the dependency was simulated.
Technical and live tests should have authorised environments, representative data, rollback procedures, defined stop conditions and a named safety controller.
Cyber scenarios should use controlled simulation rather than uncontrolled malicious activity.
A test must not jeopardise actual deposit insurance administration or expose confidential member bank or depositor information.
PIDM should use a standard test design profile so that results are comparable and auditable.
|
Stage |
Required activity |
Principal output |
|
1. Define |
Confirm the CBS outcome, Sub-CBS scope, severe but plausible scenario and approved tolerance. |
Approved test charter. |
|
2. Validate |
Confirm dependency maps, baseline workload, participants, external interfaces and assumptions. |
Validated scenario design profile. |
|
3. Prepare |
Assign controllers, observers and participants; establish injects, evidence collection and safety controls. |
Test plan and readiness approval. |
|
4. Execute |
Introduce disruptions, observe actual decisions and measure service performance. |
Inject log, service metrics and decision records. |
|
5. Assess |
Compare outcomes against each applicable impact tolerance condition and identify failed assumptions. |
Impact tolerance assessment and test report. |
|
6. Improve |
Assign remediation, approve risk treatment, track implementation and retest material weaknesses. |
Remediation register and closure evidence. |
At minimum, the test should capture the disruption start time, detection time, escalation time, continuity activation time, minimum service capacity, affected member banks, outstanding workload, data discrepancies, availability of authoritative information channels and time of verified restoration.
Where a threshold is not relevant to a particular test, the design profile should explain why. For an integrated exercise, assess all applicable CBS-level tolerance dimensions.
A test should not be successful simply because participants followed their plans.
The determining question is whether CBS-1 continued delivering its essential outcomes without unacceptable harm.
Bank Negara Malaysia's Operational Resilience Discussion Paper, issued on 19 December 2025, sets out its emerging direction for strengthening the continuity of critical financial services.
It discusses concepts and possible developments in the regulatory framework; it is not itself a final policy imposing a new set of binding scenario-testing requirements.
The paper defines its financial institution population to include specified banking institutions, insurers, takaful operators, prescribed development financial institutions, designated payment system operators and eligible electronic money issuers. PIDM is not expressly included in that definition.
Accordingly, the discussion provides a relevant methodological benchmark, but its direct legal applicability to PIDM must not be assumed.
The following table distinguishes content BNM explicitly discusses from recommendations developed for this PIDM guide.
|
BNM Discussion Paper content |
Relevance to scenario testing |
Recommended PIDM implementation |
|
Critical service outcomes. Paragraphs 3.2–3.3 describe operational resilience as critical operations or services withstanding severe but plausible disruption within acceptable limits. |
Testing must demonstrate continuity of the critical service, not merely recovery of individual components. |
Assess CBS-1 outcomes across all participating Sub-CBS and record whether essential administration remains available and trustworthy. |
|
Dependency mapping. Paragraph 3.3 identifies relationships across people, processes, data, technology, facilities and external providers as important to understanding failure propagation. |
Test scope should reflect validated dependencies and concentration points. |
Link each test to the CBS-1 dependency map; deliberately challenge shared infrastructure, information hand-offs and cross-CBS relationships. |
|
Third-party arrangements. Paragraph 3.3 discusses the need to understand external dependencies, contingency plans and viable alternatives for critical third-party services. |
A test may overstate resilience if it assumes an external provider remains available. |
Include relevant providers or member bank representatives in selected exercises and validate alternatives rather than assuming substitutability. |
|
Disruption tolerances. Paragraph 3.3 describes tolerances in terms of duration, harm and minimum operating levels. |
A technical recovery target alone cannot establish whether a test passed. |
Assess duration, capacity, information integrity, statutory obligations and stakeholder consequences against PIDM-approved thresholds. |
|
Severe but plausible testing. Paragraph 2.9 states that isolated failure tests are insufficient and highlights concurrent scenarios; paragraph 3.3 discusses challenging assumptions and multilayered failures. |
Tests should be sufficiently challenging to expose weaknesses rather than confirm favourable assumptions. |
Conduct compound exercises involving cyber compromise, unavailable personnel, failed alternatives and incomplete recovery. |
|
Technology and cyber resilience. The paper discusses cyber incidents, technology failures, compromised information, shared infrastructure and the relevance of existing technology-risk requirements. |
Availability, integrity and recovery capability must be tested together. |
Combine cyber incident response with business processing, clean-data restoration, independent reconciliation and controlled return to service. |
|
Governance and improvement. Paragraphs 3.4–3.5 discuss board and senior management ownership, adequate resourcing, periodic review, updated testing and learning from disruptions. |
Testing results should influence management decisions and future resilience capability. |
Require management review of material findings, funded remediation, accountable closure and retesting. |
The first column summarises BNM's discussion.
The third column contains implementation recommendations for this guide and should not be represented as instructions directly imposed on PIDM by BNM.
The Discussion Paper explains that BNM's existing Business Continuity Management policy addresses critical business functions, continuity objectives and dependency identification, while its Risk Management in Technology policy addresses technology resilience, security and recovery.
It also describes outsourcing-related controls for external dependencies. The application of those policies depends on the institution and the relevant policy scope.
For a Malaysian financial institution subject to those policies, the scenario-testing programme should connect applicable BCM, technology, cyber and third-party controls to critical-service outcomes. This avoids treating separate compliance exercises as sufficient proof of end-to-end resilience.
For PIDM, a practical approach is to maintain a regulatory applicability register that distinguishes actual statutory and policy obligations from discussion-paper concepts and voluntarily adopted good practices.
BNM's paper refers to disruptions involving technology migration, payment and settlement infrastructure, power failures, banking channel outages, failed disaster recovery testing and ransomware.
It also identifies the significance of common infrastructure and third-party concentration.
These examples support examining complex failure pathways.
They do not establish that BNM prescribes the specific PIDM tests proposed here.
For CBS-1, appropriate adaptations include failed premium calculation changes, simultaneous loss of information submission and recovery channels, compromised authoritative coverage records, and loss of depositor communication during financial stress.
Payment and settlement disruption is relevant to PIDM's premium collection arrangements only to the extent that the actual dependency map confirms such reliance. It should not be treated as though PIDM operates a retail payment or securities settlement service.
Scenario Testing should produce management decisions and demonstrable resilience improvements, not simply an exercise completion report.
Each finding should be linked to the affected Sub-CBS, the end-to-end CBS consequence, the relevant tolerance boundary and the underlying weakness.
PIDM should distinguish a failed control from an unrealistic assumption, inadequate capacity, unclear decision authority or an external dependency that cannot be substituted.
|
Finding |
Required management response |
Evidence of closure |
|
Potential or actual Impact Tolerance breach |
Identify the failure pathway, approve interim protection and assign permanent remediation. |
Approved action plan, implementation evidence and successful retest. |
|
Data integrity or recovery weakness |
Strengthen authoritative records, backups, verification and business acceptance. |
Recovery results, independent reconciliation and signed acceptance. |
|
Technology or third-party concentration |
Assess common failure domains and establish viable alternatives or compensating controls. |
Architecture review, third-party assurance and alternative-capability test. |
|
Inadequate capacity |
Determine the minimum workload required and increase or reallocate processing capability. |
Representative stress test and backlog clearance measurements. |
|
Delayed escalation or unclear authority |
Revise decision rights, triggers, communications and crisis procedures. |
Approved procedures, delegation records and repeat exercise. |
|
Unverified test assumption |
Obtain supporting evidence or redesign the test to challenge the assumption directly. |
Updated design profile and supplementary test results. |
The CBS owner should be accountable for confirming whether the service remained within tolerance. Test controllers and observers should preserve the evidence supporting that conclusion.
Senior management should review material weaknesses, residual risks, remediation priorities and resource requirements. Board or Board Risk Committee reporting should follow PIDM's established governance arrangements and include significant tolerance breaches, unresolved concentration risks and progress against material actions.
Close a remediation item only when implementation evidence shows the weakness has been addressed.
Where appropriate, PIDM should conduct a repeat test to establish that the improvement works under the original severe conditions.
PIDM should update scenarios when there are material changes to coverage requirements, member bank reporting, premium administration, technology architecture, operating locations, third-party arrangements or connected critical business services.
Incidents, near misses, control failures and independent review findings should also trigger scenario reassessment.
The programme should periodically revisit scenarios that previously passed. Changes in workload, technology or dependencies may invalidate earlier results.
Scenario Testing is essential to validating whether PIDM can maintain CBS-1: Deposit Insurance Protection Administration within its approved Impact Tolerance during severe but plausible disruption.
The 18 recommended Sub-CBS tests provide detailed evidence about individual operational capabilities, while the four integrated exercises establish whether those capabilities collectively preserve the end-to-end service.
This approach exposes vulnerabilities that isolated disaster recovery, business continuity or departmental exercises may not reveal.
Severe but plausible scenarios define the disruptive conditions, and Impact Tolerance establishes the boundary against which the resulting service performance must be assessed.
Cyber and ICT risks are incorporated into the operational scenarios because compromised information, failed infrastructure, unavailable access and unreliable recovery arrangements can create cascading consequences across multiple processes.
Test plans, event records, service measurements, reconciliation results and management decisions provide the evidence needed to assess preparedness.
Subsequent implementation records and retesting demonstrate whether identified weaknesses have been addressed.
PIDM should use the findings to develop lessons identified, assign remediation, prioritise resilience investment, strengthen risk treatment and continuously improve its ability to deliver deposit insurance protection administration during disruption.
The principal test outcome is not whether every system recovers. It is whether PIDM can continue or safely restore the essential CBS-1 service without exceeding the level of harm it has formally determined to be acceptable.
| 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 |
Gain Competency: For organisations looking to accelerate their journey, BCM Institute’s training and certification programs, including the OR-5000 Operational Resilience Expert Implementer course, provide in-depth insights and practical toolkits for effectively embedding this model.
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. |
||
|
|