Three Steps to Reporting ICT-Related Incidents under DORA

With the Digital Operational Resilience Act (DORA), the reporting of ICT-related incidents has become a binding regulatory obligation for financial entities. Reporting is not a one-off notification, but a multi-step, clearly structured process that requires well-founded decisions, extensive data collection and close internal coordination.

The reporting process can be divided into three key steps.

Step 1: Classification – Does an ICT-Related Incident Exist?

The first step is to assess whether an event qualifies as an ICT-related incident within the meaning of DORA.

According to DORA Article 3(8), an “ICT-related incident” is an unplanned event, or a series of related unplanned events, that compromises the security of network and information systems and has adverse effects on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity.

At this early stage, financial entities must already collect and assess relevant information, in particular:

• the nature and cause of the event
• whether it is a single incident or a series of related events
• the impact on the security of network and information systems
• the impact on the availability, authenticity, integrity or confidentiality of data or on the services provided

Incorrect classification may result in reportable incidents being overlooked or unnecessary reports being submitted.

Step 2: Assessment – Is the ICT-Related Incident Severe?

If an ICT-related incident is identified, the next step is to assess its severity. Only severe ICT-related incidents are subject to mandatory reporting to the competent supervisory authorities.

According to DORA Article 3(10), a “severe ICT-related incident” is an ICT-related incident that has extensive adverse effects on the network and information systems that support critical or important functions of the financial entity.

The assessment is based on predefined criteria, including:

• disruption of critical or important functions
• loss, compromise or unauthorised access to data
• number of affected customers or business processes
• duration, scale and, where relevant, geographical spread of the disruption
• financial losses
• reputational damage

This assessment must be clearly documented and forms the basis for the subsequent reporting process.

Step 3: Reporting – Initial, Intermediate and Final Reports

Once an incident has been classified as severe, reporting begins as a continuous process throughout the lifecycle of the incident.

1. Initial Report

Shortly after identification, an initial report must be submitted. It contains a preliminary description of the incident, its impact and the mitigation measures already taken.

2. Intermediate Reports

During incident handling, intermediate reports must be submitted whenever new relevant information becomes available, for example:

• updated root-cause analyses
• changes or refinements in impact
• progress in remediation and recovery

3. Final Report

After the incident has been resolved, a final report must be submitted. This includes in particular:

• a detailed root-cause analysis
• a description of the implemented solutions and corrective measures
• losses and costs resulting from the ICT-related incident

All reporting stages require the completion of numerous structured mandatory fields, which must be completed fully, consistently and within strict timelines.

High Operational Effort Without Structured Support

Implementing this three-step process without appropriate processes and technical support is highly resource-intensive. This includes repeated manual data collection, significant coordination efforts between IT, information security, risk management and compliance, repeated updates of identical information across reporting stages, and an increased risk of errors under time pressure.

DORA makes it clear that ICT incident reporting is a permanent governance and control process, not ad-hoc reporting.

Conclusion

Reporting ICT incidents in accordance with DORA is a significant challenge for financial institutions. Those that standardize and technically support this process at an early stage not only reduce regulatory risk but also sustainably strengthen their digital operational resilience. With the right solution, such as Leno, you are fully prepared to meet these requirements.