Banks do not need an attacker to suffer a serious ICT incident
The Basel Committee’s report on ICT Risk Management is interesting because it focuses on something that sometimes receives less attention than cyberattacks: non-malicious ICT incidents that disrupt critical banking services.
The study shows that the most frequently reported root causes are surprisingly familiar:
➡️ change control gaps,
➡️ weaknesses in system design, development and testing,
➡️ capacity and performance problems,
➡️ failures of external dependencies and technology providers.
Photo: jcomp na Magnific
Change-control gaps were the most frequently cited root cause, even though banks in most jurisdictions were assessed as having relatively mature change-management practices. Eight jurisdictions identified change control as a leading cause of incidents.
Banks already have mature governance structures, defined ICT risk management, formal change processes, testing, incident management, BCP, DRP.
Modern banking environments are enormously complex.
➡️One internationally active bank participating in the industry outreach reported more than 5 million changes in 2025.
➡️Some institutions automate up to 85% of standard, low-risk changes. At that scale, even a very small failure rate can still generate significant incidents.
➡️ In one jurisdiction, a failed system migration disrupted multiple banking channels and affected around 10% of the population.
In another case, critical banking operations were unavailable for several days.
➡️Another incident began outside the bank: unsupervised modifications to a data centre cooling system caused temperature increases and an emergency shutdown, disrupting several major banks hosted there.
This is also a very good example of Third Party Risk and nth-party dependency risk.
A bank can have mature internal controls and still suffer because a dependency several layers down the supply chain fails.
The report recommends practices such as production-like testing, dependency mapping, progressive deployments, canary releases, blue-green deployment, feature flags, tested rollback plans, automated recovery, high-availability architectures and improved monitoring. It also notes growing use of AI and ML to identify potentially dangerous changes, improve test coverage, detect anomalies and predict failures.
I have one criticism of the publication. The statistics are valuable, but I would really like to see much deeper incident case studies. Without that depth, statistics tell us what failed, but not always why. This is particularly important because, as the report itself shows, banks already have quite mature control environments.
Author: Sebastian Burgemejster
Comments