Incident data is among the most valuable inputs an operational risk programme can draw on. Risk assessments tell you what people think might go wrong. Incident data tells you what actually has. The gap between those two pictures, which is almost always larger than organisations expect when they first look honestly at it, is one of the most practically useful things any risk function can know.

The challenge is that incident data only generates genuine intelligence if the processes for capturing, investigating, and learning from incidents are well designed and well governed. Many organisations have incident reporting processes that produce a record. Far fewer have ones that produce learning. This article covers what makes the difference, from the cultural conditions that determine whether incidents are reported at all, through to the regulatory notification obligations that are increasingly specific about what must be reported externally and when.

The Foundation: Building a Reporting Culture

No process design can compensate for a culture in which people do not feel safe reporting incidents. The most common and most damaging failure in incident reporting is under-reporting, and under-reporting is almost always a cultural problem before it is a process one.

Why People Do Not Report

Staff choose not to report incidents for reasons that are entirely rational from their perspective. Fear of blame or personal consequence is the most significant. If reporting an incident leads to investigation of the individual who reported it, rather than investigation of the process or control failure that allowed the incident to occur, the lesson people take is clear. Time pressure and perceived low significance also play a role: the incident seems minor, fixing it quietly is faster, and the formal reporting process feels disproportionate to the event.

Understanding which of these factors is driving under-reporting in a specific organisation requires honest investigation, not assumption. An anonymous staff survey on attitudes toward incident reporting, a review of whether reported incidents result in individual investigation or systemic analysis, and a comparison of reported incident rates across teams with different management styles can all provide useful diagnostic data.

Leadership Behaviour Is the Primary Driver

The single most effective intervention for improving incident reporting culture is visible leadership behaviour. When senior leaders respond to incident reports with curiosity about what happened and why, rather than with criticism of the people involved, others notice. When incidents are discussed openly in team meetings as learning opportunities rather than managed quietly, others notice. When managers who surface problems are thanked rather than penalised, others notice.

The Basel Committee on Banking Supervision's Principles for the Sound Management of Operational Risk are explicit that the board and senior management should establish a culture that promotes transparency and promotes the reporting of operational risk events. Culture is listed before process for a reason.

Near-Miss Reporting

Near-miss reporting is the area where cultural factors most clearly determine whether the organisation gets genuine early warning or not. A near-miss is an event that did not cause loss or harm but could have: a payment sent to the wrong account and recovered before settlement, a system access request that bypassed normal approval and was identified before it was exploited, a process error caught by a second reviewer before it reached the customer.

Near-misses are more valuable than loss events in one important respect: they reveal vulnerability without the damage. The control failure is visible, the investigation is not complicated by the need to address harm already caused, and the organisation has the opportunity to fix the underlying condition before it produces a loss.

Building near-miss reporting requires an explicit, communicated commitment that near-miss reports will be treated as positive contributions rather than as admissions of failure. And it requires following through consistently: when near-misses are reported and result in visible improvements, others are more likely to report them.

Designing the Reporting Process

Defining What Is Reportable

A fundamental design question is where the reporting threshold sits. Too high a threshold and the organisation loses visibility of the minor events that, in aggregate, reveal systemic weaknesses. Too low and the process generates volume without analytical value, as staff spend time logging events too trivial to warrant investigation.

Most frameworks use a tiered approach. Significant incidents above a defined financial threshold require a formal report, root cause investigation, and board or committee visibility. Minor incidents below the threshold are captured in a log for aggregate analysis but do not require individual investigation. Near-misses of any size are encouraged regardless of financial threshold.

The threshold should be reviewed periodically: as the organisation grows, a fixed financial threshold that was once meaningful may capture only a small proportion of the events worth examining.

A Consistent Classification Taxonomy

When different teams classify the same type of incident differently, the aggregated data cannot reveal the patterns that are most valuable for risk management. A consistent taxonomy, a defined set of risk categories and event types that everyone uses to classify incidents, is the prerequisite for meaningful aggregate analysis.

Most organisations align their incident taxonomy to their operational risk category structure. The Basel Committee's seven operational risk event types, internal fraud, external fraud, employment practices and workplace safety, clients products and business practices, damage to physical assets, business disruption and systems failures, and execution delivery and process management, provide a widely used reference framework that many organisations adopt as the basis for their taxonomy.

Capturing the Right Information

An incident record that captures what happened and the financial impact but not why it happened does not support the investigation and learning that is the purpose of the process. Each significant incident record should include:

A description of what happened, specific enough that someone unfamiliar with the area could understand the event. The date, time, and duration. The immediate cause, the specific trigger that directly preceded the incident. The root cause, the underlying condition that made the incident possible. The control failure, which control was absent, inadequately designed, or not operating effectively. Financial and non-financial impacts, including customer impact, regulatory concern, and management time. Initial response actions taken. And the status of any ongoing investigation or remediation.

Root Cause Analysis in Practice

The distinction between the surface cause and the root cause of an incident is one of the most important concepts in incident management. The surface cause is the immediate trigger: an incorrect data entry, a missed approval, a system failure. The root cause is the underlying condition that made the trigger possible and that, if not addressed, will produce similar incidents again.

Why Root Cause Matters

Consider a payment processing error where the wrong account number was entered. The surface cause is the data entry error. Root causes might include inadequate system validation that failed to catch the error before processing; a dual-input requirement that was intended to catch these errors but had been routinely bypassed under time pressure; insufficient training for the staff member in the specific payment type; or an unusually high processing volume that compressed the time available for each transaction.

Fixing the surface cause might mean correcting this specific error. Fixing the root cause requires identifying which of these underlying conditions is present and addressing it in a way that makes the failure mode harder to repeat. If the dual-input requirement is being routinely bypassed, fixing the data entry error without addressing the bypass is not a genuine remediation.

Five-Whys Analysis

The five-whys technique, asking "why" repeatedly until the underlying condition is reached, is one of the most practical root cause analysis tools for operational incidents. It is not a rigid methodology but a structured way of resisting the tendency to stop at the first plausible explanation.

For the payment error example: Why did the payment go to the wrong account? Because the account number was entered incorrectly. Why was the incorrect entry not caught? Because the dual-input check was not performed. Why was the dual-input check not performed? Because staff under time pressure routinely skip it when volume is high. Why is that happening? Because the control has no enforcement mechanism and management has not addressed the behaviour. Why has management not addressed it? Because they were not aware it was happening routinely.

The analysis has now revealed a control design problem (no enforcement mechanism), a monitoring problem (management visibility of bypass behaviour), and potentially a cultural problem (pressure that leads to shortcuts). These are the conditions to address, not the specific incorrect entry.

Ishikawa and More Structured Methods

For more complex incidents with multiple contributing factors, structured tools such as the Ishikawa (fishbone) diagram, which maps causes across people, process, technology, environment, and management dimensions, provide a more thorough framework for comprehensive cause identification. These methods are particularly useful for significant incidents where a superficial root cause analysis would risk missing important contributing factors.

Closing the Loop: From Incident to Improvement

The most common reason incident reporting fails to drive improvement is not inadequate investigation. It is the absence of a closed feedback loop between the finding of the investigation and confirmation that the underlying condition has actually been addressed.

Remediation Ownership and Tracking

Every significant incident investigation that identifies a root cause should result in a remediation action with a named owner, a defined timeline, and a mechanism for verifying that the action has been completed and was effective. Remediation actions tracked on a spreadsheet with no systematic follow-up consistently underperform against actions tracked in a system with automated reminders and escalation.

The risk function should monitor the status of outstanding remediation actions and escalate systematically where deadlines are missed or where actions are marked complete without adequate evidence of effectiveness.

Feeding Findings Back Into the Risk Framework

An incident that reveals a significant control failure should not only generate a remediation action. It should update the residual risk rating for the relevant risk in the RCSA, because the control failure means the risk position was worse than the assessment reflected. If the control failure was not unique to the specific incident, the assessment for all risks that depend on the same control should be reviewed.

This connection between incident findings and the risk assessment is one of the markers of a mature operational risk framework. Without it, the RCSA and the incident log operate as separate records of the risk environment rather than as integrated views of the same underlying position.

Trend Analysis and Pattern Identification

Individual incidents are data points. The analytical value of incident data is primarily in what it reveals in aggregate over time. Regular analysis of incident data should look for: which risk categories are generating the most incidents or the largest losses; whether specific business units or processes account for a disproportionate share; whether frequency or severity is trending in either direction; and whether the pattern of incidents is consistent with what the RCSA would predict.

When incident trends identify patterns that contradict the risk assessment, that contradiction needs to be resolved. An area with a consistently clean RCSA and a steady stream of minor incidents either has a risk assessment problem or an incident classification problem, and identifying which is the starting point for the investigation.

Regulatory Notification Obligations

For many organisations, incident reporting is not only an internal risk management discipline. A growing set of regulatory requirements specifies what must be reported externally, to which authority, and within what timeframe.

DORA Incident Reporting

The Digital Operational Resilience Act, which came into application in January 2025, requires EU financial entities to classify, manage, and report ICT-related incidents following a defined process. Major ICT-related incidents must be reported to the relevant national competent authority through a three-stage process: an early warning within four hours of classifying the incident as major, an intermediate report within 72 hours, and a final report within one month of the incident being resolved.

The classification criteria for what constitutes a major incident under DORA are defined in EBA regulatory technical standards and cover thresholds related to client impact, service downtime, data loss, geographic spread, and economic impact. Meeting these reporting timelines requires genuinely tested detection and escalation processes, not just a plan that has never been exercised.

FCA and PRA Requirements

The FCA's systems and controls sourcebook (SYSC) requires regulated firms to have appropriate systems and controls for identifying and managing the risks arising from their operations, including the processes for identifying and reporting operational risk events. Significant incidents that affect the firm's ability to provide services, that cause material customer detriment, or that involve regulatory breaches may trigger notification obligations to the FCA depending on the nature of the firm's regulatory permissions.

The PRA expects regulated firms to notify it of operational risk events that are material to the firm's safety and soundness or to the stability of the financial system.

Data Protection Breach Notification

For incidents involving personal data, the UK GDPR and EU GDPR impose separate notification obligations. A personal data breach that is likely to result in risk to the rights and freedoms of individuals must be notified to the Information Commissioner's Office within 72 hours of the controller becoming aware of it. Where the breach is likely to result in high risk to individuals, those individuals must also be notified without undue delay.

The 72-hour clock runs from when the organisation becomes aware of the breach, not from when it occurred. This means the ability to identify a data breach, assess its risk implications, and notify the relevant authority is not a process that can be designed under pressure during a live incident.

Building Regulatory Notification Into the Incident Process

The operational risk incident reporting process and the regulatory notification process need to be integrated rather than operated separately. This means the incident classification process must include explicit consideration of whether regulatory notification is triggered, the notification process and responsible individuals must be defined in advance and tested, and the compliance function must be involved in significant incidents from an early stage rather than being informed after the fact.

References and Further Reading

• Basel Committee on Banking Supervision: Principles for the Sound Management of Operational Risk: https://www.bis.org/bcbs/publ/d532.htm

• FCA Systems and Controls Sourcebook (SYSC): https://www.fca.org.uk/firms/systems-controls/risk-management

• EBA DORA Guidelines on Incident Reporting: https://www.eba.europa.eu/regulation-and-policy/operational-resilience/digital-operational-resilience-act-dora

• ICO: Reporting a Personal Data Breach: https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/

• ISO 31000: Risk Management Guidelines: https://www.iso.org/iso-31000-risk-management.html