Basel Committee ICT Risk Management: The Four Root Causes of Incidents

ByRegReportingDesk

On 2 June 2026 the Basel Committee on Banking Supervision published a range-of-practices report on information and communication technology (ICT) risk management. It draws on a survey of 16 jurisdictions and centres on how global and domestic systemically important banks handle the technology failures that take critical services offline. The Basel Committee ICT risk management survey sets no new capital charge and adds no reporting template. Its value to a reporting team is different: it records the four most frequently reported root causes of non-malicious ICT incidents and documents practices that may serve as reference points for banks and supervisory authorities to adapt to their circumstances.

The report deliberately looks past cyberattacks. It complements the Committee’s 2018 cyber resilience range of practices, which covered malicious threats, and concentrates on incidents with no attacker behind them: a botched system migration, a change pushed without proper review, a data-centre cooling failure. The survey shows that non-malicious ICT incidents can materially disrupt critical banking operations and customer services, and it describes supervisory approaches including on-site examinations, ongoing monitoring, horizontal reviews and questionnaires.

For a G-SIB or a D-SIB, the report reads as a global benchmark of sound ICT risk management. For digital-only banks, the survey sought to identify ICT practices that may be relevant; the Committee cautions that the sample should not be read as fully representative of all banks or supervisory authorities in its membership. The document itself is short, with 19 numbered pages of report text, but it names the failure modes and the controls with enough precision to work against your own control inventory.

Related reading: our guide to DORA ICT incident reporting.

Where the ICT risk management report sits in the Basel framework

A range-of-practices report describes what supervisors observed across member jurisdictions. It is not a standard, not a consultation, and not a set of principles that carry a comply-or-explain obligation. The Committee is explicit that the practices documented may serve as reference points for banks and supervisory authorities to adapt to their own circumstances, and that the sample size means the findings should not be read as fully representative of every bank or authority in the membership.

That status matters for how you cite the report internally. It does not oblige any bank to do anything. The binding requirements still come from each jurisdiction’s own regime, and the report says so plainly: all 16 surveyed jurisdictions already have ICT risk management regulation or guidance in place, and the banking authority retains primary authority to issue it and to supervise against it. In the European Union, DORA is a central binding ICT-risk and digital-operational-resilience regime for in-scope financial entities, alongside other applicable EU and national prudential or supervisory requirements. Elsewhere, the applicable legal and supervisory base is jurisdiction-specific. The Basel report sits above those regimes as a comparison of practice, not as a layer on top of them.

Two adjacent Basel texts frame the survey. ICT risk is treated throughout as a subset of operational risk, anchored to the Committee’s Principles for the Sound Management of Operational Risk and its Principles for Operational Resilience. And in December 2025 the Committee issued a separate set of Principles for the sound management of third-party risk, which the ICT report references directly. Read together, they tell you where the Committee is heading: operational resilience as the outcome, ICT and third-party risk as two of the main routes to failing it.

The four root causes the survey put on record

The most useful single page in the report is the root-cause ranking. Members were asked to identify the most frequently observed causes of non-malicious ICT incidents in their supervised banks over 2022 to 2024, using the taxonomy from the Financial Stability Board’s Format for Incident Reporting Exchange (FIRE). Four causes stood out:

  • Change control gaps, cited by eight jurisdictions and the single most frequent cause. FIRE defines a change control gap as changes made to information systems or their configuration by a process lacking appropriate authorisation, review and rigour.
  • Gaps in system design, development and testing, cited by seven jurisdictions.
  • System capacity and performance issues, cited by six jurisdictions.
  • External dependency operational failure, also cited by six jurisdictions and ranked jointly third with capacity.

Change control leading the table is the finding to sit with. The survey notes that most banks run a mature change-management process, yet change control gaps still cause more incidents than anything else, a pattern the Committee reads as the product of rising architectural complexity. The industry outreach put numbers on the scale of the problem: one bank reported implementing over five million changes in 2025 while cutting its failure rate, and some large banks now automate up to 85 percent of standard, low-risk changes.

The external-dependency cause is where a single failure stops being one bank’s problem. One case study describes unsupervised modifications to a data centre’s cooling system that forced an emergency shutdown, affecting a number of major banks whose systems were hosted there. That is the concentration risk the report keeps returning to, and it is why third-party oversight sits alongside change control as a headline theme rather than a footnote.

Why non-malicious incidents belong on the risk map

A common assumption is that ICT risk reporting is really cyber reporting. The survey pushes back on that. It is built entirely around incidents with no malicious actor, and it shows how damaging they can be: a failed system migration in one jurisdiction caused a multi-channel disruption affecting around 10 percent of the population, and a comparable incident in another jurisdiction left critical banking operations unavailable for several days.

The European data points the same way. Under Article 22(2) of DORA, the European Supervisory Authorities must report each year on major ICT-related incidents. Their first annual report, covering major ICT-related incidents that occurred in 2025 and were reported under DORA, recorded 3,383 major incidents from EU financial entities; 10 percent were categorised as cybersecurity-related, system failures and external events were the main drivers, and around one third had a cross-border impact. We covered that dataset in our analysis of the ESAs’ 2025 report on major ICT-related incidents. The 2025 DORA data show that cybersecurity-related incidents accounted for around 10% of reported major incidents, while system failures and external events were the predominant incident types. That makes the Basel report’s focus on non-malicious disruption operationally relevant, but the DORA statistics do not establish that every non-cybersecurity incident was non-malicious or that the same mix applies under other incident-reporting regimes.

There is a practical crossover the report flags at the reporting boundary. In most surveyed jurisdictions, the criteria for an initial incident report do not distinguish malicious from non-malicious events, because the nature of an incident is often unclear in its early stages. So the same intake process has to handle both, and a team that has tuned its thresholds only for cyber events will misjudge the outage that starts with a change gone wrong.

The five most frequently reported ICT risk management practices

Set against those causes, the report names the five most frequently reported ICT risk management practices across the surveyed jurisdictions: ICT change management, third-party risk management, ICT continuity testing, ICT incident and problem management, and ICT project management and system development. The list reads as a direct answer to the root causes, which is the point.

Change management is the most detailed of the five. Rollback testing is widely embedded, with 13 of 15 jurisdictions reporting that banks require documented rollback plans and testing for all changes, or at least for higher-risk ones. Banks are also moving to progressive delivery to shrink the blast radius of a bad release: canary releases to a small user group, shadow traffic testing that runs a new version in parallel on copied production traffic, blue-green deployments and feature flags. Where rollback is not technically feasible after a flawed change, outreach participants described a roll-forward approach. The report separately notes that some banks may continue operating with the flaw under management-approved risk acceptance and enhanced monitoring while remediation is developed.

Continuity testing has widened beyond routine exercises that usually take place over a weekend. Some banks now activate an alternative site to process the full production workload for a week or longer, and test with unscripted scenarios such as an unexpected power failure at the recovery site itself. That is a deliberate answer to the case studies in the report where recovery slipped past the recovery time objective because a planned rollback failed or a DNS fallback did not behave as designed.

Dependency mapping is the control that keeps failing

Governance is the least surprising part of the survey. Most banks maintain a documented risk management framework reviewed at least annually, integrate ICT oversight into the board or a board-level committee, and, in 14 of the 16 jurisdictions, have set an explicit ICT risk appetite or tolerances. Banks anchor this to the three lines of defence and lean on external reference frameworks such as COBIT, the NIST standards, the ISO/IEC 27000 series and 22301, and ITIL. None of that is where the difficulty lies.

The difficulty is completeness. The report is candid that a persistent challenge is achieving traceability from business services down to the underlying ICT assets, and keeping the asset inventory and dependency map complete, especially where third-party services sit in the chain. A complete asset inventory does not deliver dependency mapping. Tracking every server and software version leaves a bank unable to say which customer-facing service goes dark when one shared component fails. Shadow IT, the systems business units run outside the central technology function, widens that gap, and banks reported countering it with network discovery, scanning and centralised procurement controls.

Obsolescence is the quieter half of the same control. Tracking third-party support timelines and replacing assets before vendor support ends is treated as standard practice; where immediate replacement is not feasible, banks isolate the asset with strict access controls or run a transition plan signed off by the ICT risk committee. The recurring theme across governance, inventory and third-party risk is visibility, and the survey keeps finding it thin at the edges of the estate.

Third-party visibility and the nth-party blind spot

Third-party risk earns its place among the top five practices, and the report catalogues how banks manage it: risk-based due diligence over the life of the arrangement, ongoing performance monitoring, and audits, including pooled audits where several banks share a provider. On the contractual side it names right-to-audit clauses, incident-notification clauses, data-portability terms and step-in rights, which let a bank temporarily take over a provider’s service when the provider fails to keep it running. Exit strategies and contingency planning are treated as essential for critical providers, not optional extras.

The blind spot is the nth party. Banks reported difficulty seeing past their direct providers into the subcontractors and supply chains behind them, which is where concentration risk and cascading failure points hide. This is the gap the Committee’s December 2025 Principles for the sound management of third-party risk are built to close; those twelve principles set expectations for banks in principles 1 to 9 and for supervisors in principles 10 to 12, and the ICT report cites them as the companion text. At the industry outreach, panellists welcomed the EU’s DORA oversight of critical ICT third-party providers, and suggested that requiring providers to disclose a software bill of materials would help banks manage vulnerabilities across that chain.

For EU firms this is not abstract. DORA requires financial entities to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers, distinguishing arrangements that support critical or important functions from those that do not. Financial entities report specified information on new arrangements to competent authorities at least yearly and must make the full register, or requested sections, available on request. ICT third-party service providers designated as critical are subject to the Union Oversight Framework, with one of the three ESAs appointed as Lead Overseer for each critical provider. If your bank reports in the EU, the practical build is described in our walkthrough of the DORA register of information. UK-authorised firms work to a different instrument, the PRA and FCA outsourcing and third-party rules, which is a reminder that the Basel benchmark lands on a different legal base in every jurisdiction.

How supervisors check ICT risk, and why reporting still diverges

The report’s second half looks at the supervisor’s side, and it is the section a reporting officer should read most carefully, because it shows what evidence authorities collect and how little of it is harmonised. Most jurisdictions supervise ICT risk through a risk-based, tailored mix of on-site inspections, thematic reviews, off-site monitoring and questionnaires. Several surveyed jurisdictions regularly collect ICT-risk information irrespective of the supervisory cycle. The most frequently collected items include audit reports and findings, information on critical third-party ICT providers, documentation of key systems and information on disaster-recovery or business-continuity facilities.

Incident reporting is where the divergence is starkest, and it is the trap for any group that assumes a global template exists. All surveyed jurisdictions require banks to report ICT incidents, but the criteria and thresholds vary. Severity is the most widely used trigger, alongside the duration of the outage, the criticality of the systems affected, whether data was lost and the sensitivity of any information leaked. Timelines diverge just as much: one jurisdiction requires immediate notification, while another requires a full incident report within five days of the initial notification. There is no single Basel deadline to design to, which is precisely why the report is a benchmark and not a rule.

Supervisors also do more than inspect. Half of the respondents publish aggregated reports built from incident data, while surveyed jurisdictions also report activities including exercises and crisis simulations, speeches, advisories and public-private action groups. In the EU that supervisory posture shows up in tools such as the ECB’s IT risk questionnaire, covered in our note on the ECB IT risk questionnaire in the SREP; the Basel report is the global version of the same instinct to standardise the questions while the reporting obligations stay national.

What reporting teams should take from a non-binding report

Because the report creates no filing, the temptation is to file it away. That underuses it. The more productive move is to run your own control set against the four root causes and the five practices, and to read the case studies as failure modes your supervisor has now seen described in a Basel document. If your change-approval evidence, your dependency map, your continuity-test scope or your nth-party visibility is thinner than the practices the report treats as common, that is the gap an examiner can now point to.

The talent and automation threads are worth carrying into planning. The survey flags persistent skills shortages in cyber security, cloud engineering, data management, generative AI and legacy skillsets such as COBOL and mainframe administration, and banks are responding through university partnerships and internal technical career tracks. On automation, the outreach describes AI and machine-learning tooling being used to identify change-related issues, improve test coverage, support root-cause analysis and predict incidents, while retaining human oversight for critical decisions. The report cautions that over-reliance on automation without human oversight can introduce additional risk in complex scenarios.

For EU institutions, map each Basel theme onto the DORA provisions that bind you and the operational risk management framework in Article 323 CRR. The EBA’s Article 323(2) operational risk management RTS are currently draft and under consultation until 31 December 2026; they are not yet binding. See our explainer on the EBA operational risk management RTS. For everyone else, the equivalent exercise is mapping the themes onto your own supervisor’s guidance. Either way the report becomes a gap analysis rather than a document you read once.

Frequently Asked Questions

Does the Basel Committee’s ICT risk management report create a new reporting obligation?

No. It is a range-of-practices report that describes observed practices and supervisory approaches; it imposes nothing. Any obligation to report ICT incidents or maintain an ICT risk framework comes from your own jurisdiction’s regime, such as DORA in the EU or a national supervisory rulebook elsewhere.

How is a range-of-practices report different from the Principles for Operational Resilience?

The Principles for Operational Resilience are BCBS guidelines setting out a principles-based approach to improving banks’ operational resilience. A range-of-practices report is descriptive: it documents observed bank and supervisory practices that may serve as reference points rather than creating a new principle set or comply-or-explain mechanism.

Which banks and jurisdictions were in scope?

The survey drew on 16 jurisdictions and focused on global and domestic systemically important banks, with attention to digital-only banks as banks of interest. The incident-cause analysis in Section 2 reflects 12 jurisdictions for the 2022 to 2024 period. The Committee cautions that the sample is not fully representative of all banks or supervisors in its membership.

Do we have to report incidents using the FSB FIRE taxonomy?

Not by virtue of this report. FIRE is the Financial Stability Board’s common Format for Incident Reporting Exchange, finalised in April 2025, and the Basel Committee used its taxonomy to categorise survey responses. Whether you report to your supervisor in a FIRE-aligned format depends on whether your own authority has adopted it, not on the Basel report.

Does the report set a recovery time objective or a backup standard?

No fixed figures. It observes that jurisdictions commonly set expectations around business impact analysis, recovery time and recovery point objectives, maximum allowable downtime and data backups, and that a majority have guidance on immutable backups. Those numbers are calibrated in national regimes, not in the Basel report.

How does this interact with DORA for EU firms?

DORA already imposes binding requirements on ICT risk management, incident classification and reporting, resilience testing and third-party oversight, including direct Union oversight of critical ICT providers. The Basel report is consistent context rather than an added EU requirement; the outreach panellists cited DORA’s critical-provider oversight as a model other jurisdictions are watching.

Key Takeaways

  • The Basel Committee ICT risk management report, published 2 June 2026, is a range-of-practices document: a benchmark, with no new template, deadline or capital charge.
  • Change control gaps are the most frequently cited root cause of non-malicious ICT incidents, named by eight of the surveyed jurisdictions, ahead of design and testing gaps, capacity issues and external dependency failure.
  • Run your control set against the four root causes and the five most common practices; a thinner change-evidence trail or dependency map than the report treats as normal is the gap an examiner can cite.
  • A complete asset inventory does not deliver dependency mapping; traceability from business service to ICT asset, and visibility into nth-party subcontractors, are the completeness gaps the survey keeps finding.
  • There is no single Basel incident deadline: criteria and timelines vary by jurisdiction, from immediate notification to a full report within five days, so design to your own supervisor’s thresholds.
  • For EU firms, map each Basel theme onto the binding DORA provisions and the Article 323 CRR operational risk framework; the EBA’s Article 323(2) RTS remain under consultation until 31 December 2026 and are not yet binding.
  • Keep human oversight over AI-assisted change, testing and incident tooling; the report cautions that over-reliance on automation without human oversight can introduce additional risk in complex scenarios.

Sources and References

Reading the report against your own supervisor

The report gives banks the frame its member supervisors are using. The next step for a reporting team is concrete: pull the four root causes and five practices into a gap analysis against your own control evidence, then map each theme to the instrument that actually binds you, DORA in the EU or your national ICT guidance elsewhere, so the benchmark turns into a list of controls to strengthen before the next on-site review.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts