Bank Incident: Dashboard Before Response Plan?
A retail bank with 22,000 staff and 140 critical third-party vendors processes 3,200 operational incidents a year. Last November a ransomware attack on a payment vendor caused 36 hours of downtime, affected 11,000 customers, and cost $2.8 million in remediation. The bank’s risk appetite says it has “low tolerance for prolonged service disruption,” but no quantitative time limit is defined. The operational risk dashboard contains 60 key risk indicators; 55 are green. Thresholds were set as three standard deviations from the prior 12-month average, not from appetite. The incident response plan is 90 pages and was last tested two years ago in a tabletop exercise that did not include IT operations or the vendor. Third-party risk assessments are annual questionnaires. The board receives a 40-page monthly pack and has 10 minutes for risk. The regulator has issued two findings: insufficient monitoring and weak communication with affected customers. The CRO wants a “better dashboard” before changing the incident response plan.
1. Redesign monitoring and review so that the dashboard supports the stated appetite. What should change in indicator selection, thresholds, and review?
Read the worked answer
The dashboard is not linked to the stated appetite, so green indicators can coexist with a serious disruption. Redesign should start with the appetite statement: define what “prolonged service disruption” means in measurable terms-maximum hours of unavailability for critical services, maximum customers affected, maximum transaction failure rate, and recovery time objectives for critical vendors. Then:
- Select indicators that are leading and lagging: vendor concentration, patching and identity controls, incident response test results, mean time to detect/respond, third-party assessment quality, customer complaint volume, and regulatory findings. Sixty indicators is too many; prioritize those tied to critical services and tolerance.
- Set thresholds from appetite and tolerance, not three standard deviations from a rolling average. A statistical threshold can normalize poor performance. Use green/amber/red defined by decision triggers, with escalation rules.
- Review frequency by risk: critical vendors and payment services monthly or real-time; lower risks quarterly.
- Include review, not just monitoring: a forum with authority to act, challenge, and commission testing. Monitoring produces data; review interprets it and decides.
- Independent assurance: internal audit or second-line review of vendor controls and incident readiness.
The CRO should also track treatment actions and test results, not only incident counts. A “better dashboard” without changed thresholds, review authority, and action will reproduce the same blind spot.
2. Assess the communication and consultation failures in the incident and propose improvements for internal and external stakeholders.
Read the worked answer
Communication and consultation (6.1) failed before, during, and after the incident.
- Before: the incident response plan was not tested with IT operations or the vendor, so roles, contacts, and decision rights were untested. Customer communication templates and regulatory notification criteria were not exercised. Staff and customers were not consulted about service criticality.
- During: 36 hours of downtime suggests delayed detection, escalation, or customer notification. The regulator found weak communication with affected customers. There was no evidence of a pre-agreed spokesperson, channel, or accessible messaging.
- After: the CRO wants a dashboard before fixing the response plan, which reverses the learning priority.
Improvements:
- Map stakeholders: affected customers, regulators, the vendor, payment schemes, internal operations, frontline staff, and the board.
- Pre-agree escalation triggers, roles, channels, and message templates; test them in realistic exercises with the vendor and IT.
- Define regulatory notification timelines and customer remediation commitments.
- Consult customer-facing staff on what customers need to know and when.
- Build two-way feedback: customer complaints, regulator questions, and vendor lessons should feed risk review.
- Report incident communication performance to the board, not just downtime.
Communication is not a press release at the end; it is a continuing process that shapes risk understanding and trust.
3. What should the CRO do to turn the incident into continual improvement, and why is a “better dashboard” insufficient?
Read the worked answer
The CRO should treat the incident as a trigger for review and continual improvement (5.6), not as a reason to improve presentation. A better dashboard may help, but it is an output; the underlying capability is monitoring, decision-making, testing, and accountability.
Actions:
- Conduct a post-incident review with IT, the vendor, business continuity, compliance, and customer service; identify root causes and control failures.
- Re-test the incident response plan with realistic scenarios, including vendor failure, and set a schedule (e.g., twice yearly, with one live technical exercise).
- Strengthen third-party oversight: risk-tier vendors, require evidence of controls, set contractual notification and recovery requirements, and monitor concentration.
- Update risk criteria and appetite statements with quantitative service tolerances.
- Assign owners and deadlines for treatment; report progress to the board.
- Measure effectiveness: time to detect, time to recover, customers notified within target, regulatory findings closed, exercise actions completed.
- Feed lessons into training, procurement, and the risk register.
A dashboard can support this only after indicators, thresholds, and review authority are linked to appetite. The CRO should resist a “dashboard first” sequence because it can create an illusion of control while the response plan, vendor oversight, and communication remain untested. Continual improvement requires changed behavior and verified capability, not more indicators.