Third-Party Payment Outage and Data Breach
On a payday Friday, the bank's third-party card payment processor suffers a nine-hour outage. About 12,000 customers cannot complete card and wallet transactions. At 14:00 the bank's security team detects an unauthorised administrator login from an overseas IP address. The processor's forensic update at 20:00 confirms that tokenised card data for 8,000 customers may have been accessed, but no PINs or passwords were exposed. The processor is hosted in a shared cloud region and provides services to three other banks. The bank's incident playbook has not been tested since last year. The COO wants to wait for full forensic confirmation before notifying the regulator and customers; the CISO wants immediate notification. The Board asks for an assessment of operational, regulatory and reputational risk.
1. Classify the incident and assess the notification obligations and timing.
Read the worked answer
The incident is a material operational and cyber incident, not just a vendor outage. It combines availability failure, unauthorised access and potential personal-data breach. Waiting for full forensic confirmation is not appropriate: under BNM's Risk Management in Technology expectations, material cyber incidents must be escalated and notified to BNM promptly, with updates as facts develop; under the PDPA, if a data breach is likely to cause significant harm, the bank should notify the Commissioner and affected individuals within the required timeline, including the 72-hour Commissioner notification. The bank should make an initial notification without speculation, preserve evidence, and coordinate with the processor. The COO's wait position risks regulatory breach and reputational damage. The CISO's immediate escalation is sound. The Board should also consider whether the incident is a reportable outsourcing disruption and whether other banks using the same processor are affected.
2. Identify the operational and third-party risk issues that root cause analysis should cover.
Read the worked answer
Root cause analysis should cover the processor's identity and access management, privileged account controls, network segmentation, patch management and incident response. The overseas admin login suggests weak privileged access controls or credential compromise. The bank should obtain the processor's forensic report, contract audit rights, sub-processor list and cloud-region resilience plan. Third-party concentration is a key risk: one shared cloud region serving four banks creates correlated outage. The bank should review exit plans, data portability, backup processing and contractual notification SLAs. Operational risk capital and scenario analysis should reflect a nine-hour outage at payday, including customer compensation and regulatory fines.
3. Recommend a remediation and Board reporting plan.
Read the worked answer
Remediation should be prioritised by risk: immediate containment and token or password reset for affected customers; an independent forensic review; processor remediation of privileged access and segmentation; bank-side transaction monitoring; customer communication and complaints handling; contract renegotiation with audit and exit rights; and a board-approved outsourcing contingency plan with a tested playbook. The Board should receive a timeline, root cause, customer impact, regulatory notifications and lessons learned. The bank should not simply accept the processor's assurance; it should verify. The Board should also challenge whether the bank can switch processors or run a manual fallback within an acceptable time.