Mastering DORA Core Topics: A Deep Dive into Incident Management
DORA
DORA is primarily a comprehensive ICT risk management framework. The aim is to ensure that all financial organisations can withstand, respond to and recover from all types of ICT-related incidents and threats.
DORA is structured in such a way that all the thematic focus areas, all the pillars, are addressed in other pillars. Everything is interlinked. There are cross-references throughout the law and the associated technical regulatory standards, technical implementation standards and guidelines.
Incident management cuts also across all 5 pillars.
Core elements in DORA with a focus on incident management
ICT risk management defines the basis for technical requirements such as identification, protection and prevention, detection, response and recovery, and backup policies. It also provides the basis for ICT business continuity guidelines and ICT response and recovery plans. It also covers learning processes and communication strategy.
DORA requires companies to regularly conduct tests of the effectiveness of their processes. Financial organisations are audited on whether processes are tested. They should not just passively wait until something happens, but also actively act.
In the area of handling and reporting ICT incidents, a process for handling ICT-related incidents should be documented, established and regularly tested. In this chapter we also find specifications for incident management and reporting. The technical regulatory standards and the technical implementation standards are also an important part of this pillar. These documents define the requirements for incident classification and reporting.
The third pillar - testing of digital operational resilience - stipulates that all systems and applications that support critical or important functions must be tested regularly. Furthermore, selected financial organisations must carry out the advanced threat-oriented penetration tests - the TLPT. The aim is to identify weaknesses, deficiencies, and gaps in digital operational resilience, assess readiness to deal with ICT-related incidents and take immediate corrective action.
The ICT third party risk domain deals with topics such as contractual relationships with ICT third party providers and the EU monitoring framework for critical ICT third party service providers. However, we also find requirements for incident management here. It is stipulated that if third parties are affected, they must co-operate with financial companies in incident handling.
And the fifth pillar, which deals with the exchange of information between financial companies, the possibility for cross-sector crisis management and emergency exercises with a cyber focus to improve communication and strengthen resilience in the financial sector, will be developed.
Process for handling ICT-related incidents
How does the process of recognising, handling, and reporting ICT incidents according to DORA look like? What happens after an incident has occurred?
First, the incident must be detected in the first place. According to statistics, the attacker has often entered the system many months before the attack is discovered.
The aim of DORA is to set up certain measures to recognise the attack as quickly as possible. The sooner you realise that you have been attacked, that someone has gained access to your system, the greater is the chance of minimising the damage and saving your own data.
The next step is to respond to and deal with the incident. Once the incident has been resolved, DORA foresees certain learning tasks and processes.
All incidents must be resolved. If the incident is classified as “major” during the process, it must also be reported to the competent authorities. Significant cyber threats can be reported voluntarily.
Detection
The detection mechanisms are essentially a basis for appropriate response measures.
Article 10 of DORA requires financial organisations to implement certain mechanisms to promptly detect anomalous activity and identify potential material single points of failure.
The detection mechanisms must allow for multiple levels of control and set alert thresholds and criteria to trigger and initiate response processes for ICT-related incidents.
A financial organisation should provide sufficient resources and capacity to monitor user activity, ICT anomalies, ICT-related incidents, including cyber-attacks.
And of course - as with other processes - these should be regularly reviewed for effectiveness and put on test.
Response and recovery
In terms of response and recovery, DORA requires the establishment of a comprehensive ICT business continuity policy i.a.w. Article 11. It includes topics such as:
- the appropriate response to all ICT-related incidents to limit damage, combined with the resumption of activities and the prioritisation of recovery measures.
- the activation of plans with containment measures, processes and technologies in the event of ICT-related incidents, and
- the mandatory assessment of preliminary impacts, damages, and losses; and
- the definition of communication and crisis management measures.
DORA also requires the establishment of a crisis management function. When activating ICT business continuity plans or ICT response and recovery plans, this function should, among other tasks, define clear procedures for handling internal and external crisis communication (i.a.w. Art. 14 DORA).
Article 17 specifies the response and incident handling topics and requires the establishment of an ICT-related incident management process. Specifically, it states that
- the early warning indicators should be used,
- roles and responsibilities must be assigned,
- information must be provided to relevant senior management,
- a communication strategy must be established, and
- ICT-related incident response procedures must be established.
And again - all processes and plans must be regularly tested and trialled.
Learning and evolving
Once an incident has been resolved, a learning process follows (i.a.w. Art 13 DORA). In the case of incidents that affect critical or important functions, it is necessary to
- Carry out subsequent checks and root cause analyses of the ICT-related incident.
- Identify required improvements to the ICT operations or within the ICT business continuity policy, and
- communicated the to the competent authorities if requested.
In the post ICT-related incident reviews, the financial organisation must evaluate:
- The speed of response
- The quality of the forensic analyses
- The effectiveness of internal escalation
- The effectiveness of internal and external communication
As mentioned, the response times and the quality of the forensic analyses are examined separately after the incident has been resolved. The quality of the response will be better if you one is prepared well. The assumption in DORA is not IF an incident happens, but WHEN it happens.
Classification and reporting of the incident
As already mentioned, all incidents must be classified.
Incidents, which are classified as “major”, must be reported to competent authorities. There are three types of reports, which must be submitted within specified deadlines.
And, of course, own customers must be informed.
Classification of the ICT-related incident
The classification of the incident is based on DORA Article 18 and on a technical regulatory standard: RTS on Classification of major incidents and significant cyber threats (EU 2024/1772).
The classification process is as follows (all articles refer to the above-mentioned RTS):
1. Upon discovery of the incident, the first step is to analyse the criticality of the affected services (Art 6).
Criterion a) assesses whether the ICT services or network and information systems, which support critical or important functions, are affected (Art 6(a)).
Criterion (b) assesses whether financial services, which require authorisation or registration, or are supervised by competent authorities, are affected (Art 6(b)).
And criterion c) assesses whether there has been successful, malicious and unauthorised access to the network and information systems (Art 6(c)), which may lead to the loss of data.
2. If none of the criteria are met, the incident is not to be classified as “major”.
3. If the materiality threshold of criterion c) is met (Art 9(5)(b), Art 8(1)(a)), the incident is to be classified as “major”.
4. If criterion a) and/or criterion b) are affected, further criteria must be examined in relation to the respective materiality threshold (Art 8(1)(b) and Art 9).
- Customers, financial counterparties and transactions (Art 1, Art 9(1))
- Reputational damage (Art 2, Art 9(2))
- Duration and service downtime (Art 3, Art 9(3))
- Geographical spread (Art 4, Art 9(4))
- Loss of data (Art 5, Art 9(5))
- Economic impact (Art 7, Art 9(6) (There is a separate guideline for the calculation of costs and losses: Joint Guidelines on the estimation of aggregated costs and losses caused by major ICT-related incidents (ESAs final report JC 2024 34).
If 2 or more other criteria are met, the incident is classified as “major”.
Reporting obligations for incidents classified as “major”
Incidents classified as “major” must be reported to the competent authorities.
The reporting obligations are very brief. The initial notification must be submitted as soon as possible, but no later than 4 hours after the incident has been categorised as “major” and no later than 24 hours after the financial institution has become aware of the incident. If an incident is categorised as “major” later, the financial institution must submit the initial report within 4 hours of the categorisation.
An intermediate report must be submitted the latest within 72 hours from the submission of the initial notification.
And the final report no later than one month from the submission of the latest updated intermediate report. If the incident has not been resolved by then, the final report can of course be submitted at a later stage.
DORA Articles 19 and 20 set out the basic rules for reporting deadlines and the content of reports. There is a separate standard for the detailed requirements: RTS and ITS on incident reporting (ESAs final report JS 2024 33).
In the event of an ICT incident, it is important to react quickly and appropriately. For this reason, DORA attaches great importance to preparatory measures. One must have a thorough knowledge of one's ICT network and take measures for recognising and responding to an incident quickly.
How can SEC Consult support you?
There is no time to implement appropriate policies and procedures in the event of a cyber security incident. As part of the SEC Defence Service, we offer preparation and strategy workshops as well as crisis planning games to simulate cyber attacks. These training sessions cover the strategic, tactical, and operational levels. An important part of the preparation is also the evaluation of your organisation with a maturity assessment. The focus here is on assessing your organisation's defence capabilities.
In an emergency, our team will be at your disposal within the shortest possible time. Security experts from the fields of incident response, forensics and technical and organisational information security will immediately initiate the necessary immediate measures. Damage limitation, the prevention of a renewed attack and the rapid resumption of normal operations are our priority.
NB: all the referred Final Reports of ESAs, have been published on July 17, 2024. In the next step, they will be adopted by the European Commission, reviewed by the European Parliament and the Council. And finally published in the Official Journal of the EU.
