Core banking upgrade: go/no-go and cyber resilience
A bank with 2.1 million customers and 260 branches plans a core banking upgrade over a 52-hour weekend. User acceptance testing is 96% complete, but nine Severity-1 defects remain open, including one affecting interest accrual and one affecting standing instructions. The vendor's patch is due 18 hours before go-live and has not been regression-tested by the bank. The rollback plan exists but has never been rehearsed; the disaster recovery site is 40 minutes behind production and the bank's RTO for core banking is 4 hours. Branch staff have been trained on the new screens for only two hours, and 60% of transactions are still initiated by staff rather than customers. The regulator has been informed of the change under the bank's notification policy. The CIO must recommend go or no-go to the change advisory board and define the cyber and operational controls required if the upgrade proceeds.
1. What go/no-go recommendation should the CIO make, and why?
Read the worked answer
Recommend no-go at the current date. A 96% UAT completion rate is not the decision criterion when nine Severity-1 defects remain, including interest accrual and standing instructions, which can corrupt customer balances and recurring payments. The vendor patch arriving 18 hours before go-live and not being regression-tested by the bank creates unacceptable change risk. The rollback plan has never been rehearsed, so the bank cannot confidently recover within the weekend. The DR site is 40 minutes behind production, which is inside the 4-hour RTO only if failover works, but that is untested. Two hours of branch training for staff who initiate 60% of transactions is insufficient.
Conditional go only if every Severity-1 is closed and retested, the patch is regression-tested, rollback is rehearsed end-to-end, and DR failover is tested; otherwise defer to a later window. Record the rationale.
2. If the upgrade proceeds, what operational and cyber controls should be mandatory?
Read the worked answer
Impose hard gates: change freeze, no open Severity-1 or Severity-2 defects, vendor engineers on site, rollback trigger criteria and decision authority, a parallel run for one full batch cycle, and daily reconciliation of interest, standing instructions and GL balances. Test DR switchover and switchback before go-live. Run a war room with business, IT, cyber and vendor leads. Monitor for phishing and credential attacks during cutover. Put floor-walkers in branches and a command queue for incidents. Predefine stop-the-line criteria and communicate them.
A 'go' without these gates is risk acceptance at the wrong level. If the bank cannot meet the gates, it should defer rather than rely on vendor assurances.
3. How should the bank handle incident communication and post-implementation learning?
Read the worked answer
Prepare customer and regulatory communications before cutover: service notices, branch scripts, expected delays and complaint escalation. If an incident occurs, activate the incident response plan, use manual workarounds only with reconciliation, and update the regulator under the notification policy. Preserve logs and a timeline.
After the event, conduct a post-implementation review covering change management, testing quality, vendor performance, training and DR. Track losses and near misses in the operational risk system. The lesson is that a technically successful installation is not the same as an operationally resilient change.