Incident Management under DORA: What Risk and Compliance Leaders Need to Rethink

For risk and compliance leaders, incident management has never been optional. What DORA changes is not ownership, but expectation. Supervisors are no longer interested in whether incidents are registered. They want evidence that organisations understand what drives incidents, respond consistently, and learn structurally.

That shift requires a different way of organising incident management.

*This article is based on the webinar How to Strengthen Your Incident Management for DORA and Beyond. Access the webinar recording here.

The Reality Behind Today’s Incident Landscape

Operational risk data across European banks shows a clear pattern. Cyber risk and data security remain the dominant incident drivers, followed by IT failures, outsourcing, conduct and legal risk, and fraud. These are not isolated categories. They are symptoms of increasingly complex operating models where technology, third parties, and regulatory pressure intersect.

For risk leaders, this matters because it reinforces a key point from the webinar: incident management cannot be treated as a reactive process that starts after something goes wrong. It must be designed with the dominant risk drivers in mind and embedded into daily operations.

Incident Management Starts With a Clear, End-to-End Process

Effective incident management is not a single action. It is a structured lifecycle that starts the moment something deviates from normal operations and only ends when learninghas been embedded.

In practice, this lifecycle consists of eight connected steps:

• Incident logging
• Categorisation
• Prioritization
• Routing and assignment
• Creating and managing improvement actions
• SLA management and escalation
• Resolution
• Closure

Each step serves a governance purpose. Skipping or weakening any of them creates blind spots that typically surface during audits, incidents, or regulatory reviews.

A deliberate design choice highlighted in the webinar is to keep reporting thresholds low. Anyone should be able to report an incident easily, often via mobile devices. This can lead to multiple notifications for a single event, but consolidation belongs in the assessment phase. Early visibility is always preferable to filtered silence.

Access the webinar recording and presentation .

Root-Cause Analysis Is Where Control Becomes Visible

An incident on its own explains very little. The real value lies in understanding why it happened.

This starts with basic risk management questions:

• Was the risk already identified?
• Did a control fail, or was it not in place?
• Was the cause human, technical, third-party related, or organisational?

Structured root-cause methodologies such as fishbone analysis, bow-tie analysis, fault-tree analysis, or the five-whys technique help move beyond symptoms. They force organisations to distinguish between primary and secondary causes and to avoid superficial conclusions.

Equally important is learning. Linking incidents to other reported events and building a library of lessons allows patterns to emerge. Over time, this transforms incident management from reactive handling into proactive risk insight.

Why DORA Places Incident Management at the Centre

DORA does not primarily aim to increase reporting obligations. Its core objective is to protect the continuity of critical financial services.

Supervisors are concerned about systemic risk. Thousands of financial institutions rely on interconnected ICT systems, cloud providers, and third parties. A major disruption at one point in the ecosystem can quickly cascade across organisations.

This explains why DORA places explicit requirements on incident classification, escalation, and regulatory reporting. These requirements are not administrative in nature. They are designed to ensure institutions understand which incidents threaten critical services and respond accordingly.

What MN’s Experience for DORA Shows in Practice

The experience of MN, one of the largest pension asset managers in the Netherlands, illustrates how these principles are applied in practice.

As part of its DORA programme, MN treated incident management as a dedicated workstream. The starting point was not tooling, but a gap analysis between existing policies and processes and the new regulatory requirements. Based on this analysis, MN adjusted its incident policy and introduced new incident types required under DORA. Watch the recording how MN design their DORA program .

Only after this ground work did MN adapt its incident management tooling, introduce organisation-wide training and awareness through e-learning, and put reporting formats in place for regulatory reporting to the AFM.

This sequencing reflects a conscious leadership choice. Process clarity, roles, and accountability came before automation.

Low Threshold Reporting as a Leadership Choice

One of the important choices MN made was to allow every employee to report incidents easily.

From a risk leadership perspective, this is a trade-off. Lower thresholds lead to more reports and more work during assessment. At the same time, they reduce surprises and improve early detection. Consolidation and prioritisation take place later, under the responsibility of the second line.

This approach aligns closely with DORA’s intent and highlights the role of risk and compliance leaders in shaping reporting culture, not just control frameworks.

Incidents Rarely End Where They Start

Another lesson reinforced during the webinar is that incidents rarely remain confined to a single process or department.

At MN, incidents are assessed centrally by the second line, classified consistently, and communicated to internal stakeholders and clients based on severity. Medium and high incidents trigger board-level visibility and clear timelines.

This cross-functional view is essential. Without it, organizations fix local issues while systemic weaknesses remain untouched.

Crisis First, Documentation Second

MN’s experience with major ICT incidents also highlights an important reality.

In crisis situations, the priority is response and coordination. Restoring services and limiting impact come first. Documentation and regulatory reporting follow once stability has been restored.

For risk and compliance leaders, this nuance matters. DORA does not expect perfect form completion during a crisis. It expects timely judgement, clear ownership, and well-documented reasoning afterward. Systems should support this sequence, not work against it.

Incident Management as a Learning Discipline

What ultimately differentiates mature organisations is not how quickly incidents are closed, but how consistently lessons are embedded.

At MN, incidents are explicitly linked back to risks, controls, and improvement actions. Root-cause analysis is not treated as a formality, but as a way to challenge whether risks were underestimated or controls were ineffective.

This is where incident management becomes strategic. It feeds continuous improvement rather than periodic reporting.

A Question Risk and Compliance Leaders Should Be Asking

DORA may be the immediate driver, but it exposes a broader question.

Do incidents in your organization lead to structural learning, or do they disappear once they are closed?

Risk and compliance leaders are uniquely positioned to influence the answer. Not by owning the incident register, but by shaping how incidents are interpreted, escalated, andused to strengthen resilience over time.

That is the real shift DORA brings.

‍