As organisations become increasingly dependent on third parties, the ability to withstand and recover from third-party failures becomes a defining element of Operational Resilience.
Scenario testing is a critical tool that enables financial institutions to simulate disruptions and assess whether their Critical Business Services (CBS) can continue operating within defined impact tolerances.
Regulators such as the Bangko Sentral ng Pilipinas (BSP) and Bank Negara Malaysia (BNM) require financial institutions to conduct severe but plausible scenario testing, including scenarios involving third-party failures.
These tests must validate whether the organisation can continue to deliver essential services despite disruptions to outsourced or externally supported operations.
This chapter provides structured approaches and CBS-aligned templates for conducting scenario testing focused on third-party failures. By the end of this chapter, readers will:
Third-party failure scenarios should reflect realistic and severe disruptions, including:
|
Component |
Description |
|
Scenario Definition |
Description of disruption |
|
CBS Impact |
Critical services affected |
|
Dependencies |
Third parties involved |
|
Impact Tolerance |
MTD, MTDL thresholds |
|
Response Actions |
Steps to mitigate impact |
|
Recovery Strategy |
Restoration approach |
|
Lessons Learned |
Improvement actions |
Template: Scenario Testing for CBS (High-Level)
|
CBS |
Scenario |
Third Party |
Impact Description |
MTD |
MTDL |
Response Strategy |
Recovery Strategy |
Outcome |
Remarks |
Example: CBS-1 Deposit and Account Services
|
CBS |
Scenario |
Third Party |
Impact Description |
MTD |
MTDL |
Response Strategy |
Recovery Strategy |
Outcome |
Remarks |
|
CBS-1 |
Core banking system outage |
Core Banking Vendor |
Customers are unable to access their accounts |
4 hrs |
0 data loss |
Activate the DR site |
Switch to the backup system |
Within tolerance |
Tested annually |
|
CBS-1 |
Data breach at cloud provider |
Cloud Vendor |
Exposure of customer data |
Immediate |
Minimal |
Incident response activation |
Data recovery & containment |
Partial breach |
Improve controls |
Template: Scenario Testing for Sub-CBS
|
Sub-CBS Code |
Sub-CBS |
Scenario |
Third Party |
Impact |
MTD |
Response Action |
Recovery Action |
Status |
Example: CBS-1 Detailed Processes
|
Sub-CBS Code |
Sub-CBS |
Scenario |
Third Party |
Impact |
MTD |
Response Action |
Recovery Action |
Status |
|
1.1 |
Customer Onboarding |
KYC system failure |
KYC Vendor |
Delayed onboarding |
24 hrs |
Manual onboarding |
Restore system |
Within tolerance |
|
1.6 |
Deposit Transactions |
Payment processor outage |
Payment Vendor |
Transactions fail |
2 hrs |
Queue transactions |
Switch provider |
Exceeded tolerance |
|
1.11 |
Digital Access |
Mobile app outage |
Cloud Provider |
Customers are unable to log in |
1 hr |
Notify customers |
Failover to DR |
Within tolerance |
Template: Severe Scenario Testing
|
Scenario ID |
Scenario Description |
Type (Cyber/Operational/etc.) |
CBS Impacted |
Third Party |
Severity |
Likelihood |
Overall Risk |
Remarks |
Example Scenarios
|
Scenario ID |
Scenario Description |
Type |
CBS Impacted |
Third Party |
Severity |
Likelihood |
Overall Risk |
Remarks |
|
S1 |
Cloud provider regional outage |
Operational |
CBS-1, CBS-2 |
Cloud Vendor |
High |
Medium |
High |
Multi-CBS impact |
|
S2 |
Ransomware attack on vendor |
Cyber |
CBS-1 |
IT Vendor |
Critical |
Medium |
Critical |
Data risk |
|
S3 |
Vendor insolvency |
Financial |
CBS-2 |
Payment Vendor |
High |
Low |
Medium |
Replace vendor |
Template: Test Results and Evaluation
|
Scenario |
CBS |
Test Objective |
Result |
Within Tolerance (Y/N) |
Gaps Identified |
Action Plan |
Owner |
Timeline |
Example
|
Scenario |
CBS |
Test Objective |
Result |
Within Tolerance |
Gaps Identified |
Action Plan |
Owner |
Timeline |
|
Cloud outage |
CBS-1 |
Validate DR capability |
Success |
Y |
None |
Maintain readiness |
IT |
Ongoing |
|
Payment failure |
CBS-2 |
Ensure continuity |
Failed |
N |
No backup vendor |
Add redundancy |
Ops |
3 months |
Mapping Scenario Testing to OR Framework
|
OR Component |
Scenario Testing Role |
|
CBS |
Identify impacted services |
|
BIA |
Define impact tolerance |
|
TPRM |
Identify third-party dependencies |
|
Crisis Management |
Execute response |
|
Recovery Planning |
Validate recovery strategies |
1. Use Severe but Plausible Scenarios
Focus on realistic disruptions with significant impact.
2. Include Third and Fourth Parties
Test extended supply chain dependencies.
3. Align with Impact Tolerance
Validate against MTD and MTDL thresholds.
4. Conduct Regular Testing
At least annually for critical vendors.
5. Involve Cross-Functional Teams
Include IT, Risk, Business Units, and Vendors.
6. Capture Lessons Learned
Continuously improve resilience strategies.
Step-by-Step Approach
|
Step |
Action |
|
1 |
Identify CBS and supporting vendors |
|
2 |
Define impact tolerances (MTD/MTDL) |
|
3 |
Develop scenarios |
|
4 |
Execute tests |
|
5 |
Evaluate results |
|
6 |
Identify gaps |
|
7 |
Implement improvements |
Scenario testing is a critical component of Third-Party Risk Management and Operational Resilience. It transforms theoretical risk assessments into practical insights by simulating real-world disruptions and evaluating organisational readiness.
By aligning scenario testing with Critical Business Services and incorporating third-party failure scenarios, financial institutions can ensure that they are prepared not only for internal disruptions but also for failures across their extended ecosystem.
This capability is essential for meeting regulatory expectations under BSP Circular No. 1203 and BNM guidelines, and for maintaining customer trust and service continuity in an increasingly interconnected world.
| C1 | C2 | C3 | C4 |
| C5 | C6 | C7 | C8 |
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. |
||
|
|