DORA ICT

Written by Marta Pazderska | Dec 9, 2024 2:35:27 PM

On January 17th, 2025, the EU regulation called the Digital Operational Resilience Act (DORA) will come into force to strengthen the IT security of financial entities such as banks, insurance companies, and investment firms by making sure that the financial sector in Europe stays resilient in case of major operational disruption.

DORA comprises several chapters, such as Chapter III, which deals with ICT-related incident management, classification, and reporting.

In this post we would like to make sure that you will get familiar with the following:

basics of the content of this chapter,
impacts of IT on the ITSM process and standard ServiceNow ITSM implementation,
how ServiceNow ITSM and platform capabilities can help you to get compliant,
how to prepare for the DORA implementation project.

Let’s get familiar with the scope of Chapter III of the new regulations and related key technical standards

Chapter III	Short summary of the article content
Article 17	Financial entities must have incident management procedure which contains how to identify, track, log and categorize ICT related incidents especially according to the criticality of the services affected record ICT-related incidents assign roles and responsibilities at least major incidents are reported to senior management
Article 18	Financial entities shall classify ICT-related incidents and determine their impacts under criteria such as: number of clients/counterparts affected by the incident duration of the incident and service downtime geographical spread with regards to the areas affected by the ICT – incident data loss that the ICT-related incident entails criticality of the service impacted economic impact (direct and indirect loses)
Article 19	Financial entities shall, within the time limits submit the major ICT-related incidents following to the relevant competent authority: an initial notification; an intermediate report with detailed information final report, with the completed root cause analysis categorization and details Reporting obligation can be delegated to the 3rd party Financial entities may, on a voluntary basis, notify significant cyber threats
Article 20	The ESAs, through the Joint Committee, and in consultation with ENISA and the ECB, shall develop common draft regulatory technical standards that contains the major incident drive logic based on the criteria from Article 18, the threshold for each criterion, time limits and templates for the 3-stage reporting obligation
Article 21	Are related to ESAs and Joint Committee that shall prepare a joint report assessing the feasibility of further centralization of incident reporting.
Article 22	In case of a reported incident competent authority shall acknowledge the receipt and may, in a timely manner, relevant and proportionate feedback or high-level guidance to the financial entity on how to minimize and mitigate adverse impact across the financial sector. Without prejudice to the supervisory feedback received, financial entities shall remain fully responsible for the handling and for consequences of the ICT-related incidents.
Article 23	The requirements laid down in this Chapter shall also apply to operational or security payment-related incidents.

Full text of the regulation can be found on the DORA website and here you go are the related RTS-es.

Incident impacts drive the classification of the incident as major and related reporting:

Source: DORA Draft RTS

Understand the impact on the ITSM process – is the devil so scary how it is painted?

A few questions appeared during the gap analysis prior to the implementation of the solution that would support DORA Chapter III regulations in one of the financial entities.

Do I need to have the exact definition of the Major Incident as it is per DORA or not?
ITIL Definition of Major Incident is not really different from the simple definition of it as per DORA, which can be summarized as ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions. The difference usually is in the individual implementation of it in an organization. The DORA criteria may definitely be different than the one you developed as a practice, especially since some of the criteria are usually not possible to be estimated by the agent as part of standard incident classification process steps, e.g., economic impact, reputational loss. You can either adjust your classification practical rules to incorporate DORA criteria or manage them as a separate ‘’TAG’’ just for reporting purposes.
Timeline of the major incident management process according to DORA vs in ServiceNow?
We can observe that the introduced time limits for reporting says that you have max 4 hours from incident detection to classify the incident according to DORA criteria and max next 20 h to send initial report, next reports shall be sent within the next 3 days and 20 days respectively. As we know, the lifecycle of the incident and standard SLAs are much shorter, especially for Major Incidents. Many times, 24 hours is quite a long time. The timeline does not actually force you to keep the Incident active till the last report, you may manage the incident lifecycle as usual but ensure communication plans respect the DORA time limits.
Do I need to heavily customize the tool and OOB incident management process to get compliant?
DORA regulation does not force you to use any tool or system chance you do not need to customize your Incident process too much. Many of the standard ITSM best practices already made you compliant as far as you implemented them. Standard IM implementation in ServiceNow ensures you track and categorize incidents, you indicate affected services and register outages of services. The other ones should be embedded into related processes as per applicability e.g. analyze root cause and categorize it within related Problem Mgmt. process.

I hope you start realizing that the devil is not as scary as it is painted.

Use ServiceNow to help you to get the DORA Chapter III complaint.

When working on a DORA implementation project, the use of the following ServiceNow capabilities has been identified as helpful in getting compliant.

Incident Management – track Incident and their impacts, classification and reporting information, track incident duration
SLA Definitions – apply additional OLAs to ensure incident classification and its root cause investigation is completed on time
Assessment / Surveys – assess incidents under all DORA criteria and crossing the related thresholds, re-asses whenever needed
Problem Management – analyze the root cause of the significant incident reported
CMDB / Service Portfolio – maintain the lifecycle & business criticality of the business-critical services that the incidents may affect, maintain locations
Outages – register business critical service outages
MIM Workbench and Communication Plans – govern and distribute communication-related tasks to report on time to regulatory body
Predictive Intelligence – identify recurring incidents of the exact root cause
Reports and Dashboards – pre-identify recurring incidents of the exact root cause and help to manage the time-critical analysis

How to get ready?

Certain key aspects need to be analyzed and established before implementing any functionality in ServiceNow to support DORA Chapter III regulations.

Identify which type of financial entity your organization is, select the requirements that apply to it.
Find your local (usually specific for a country) regulatory body (competent authority) to which you will need to report to and establish the reporting channel.
Identify inventory of services that your organization offers and whether their business criticality is maintained.
Translate thresholds % into absolute numbers in your organization, do you have a mechanism to count it?
Analyze Incidents and other procedures and work instructions for agents seeking alignment with new requirements.
Remember: You can get compliance without a software tool and workflow but not without a procedure.
Embed the new 3-stage reporting obligations and their due dates into major incident communication plans, identify responsible colleagues.
Engage with the compliance team and internal audit that will validate the compliance readiness.
Review other regulations under which you are already reporting and check whether the new reporting regulation does not replace any of the previous ones.

Engage with BCM team to establish plan B in case the major incident is so damaging that you do not have even access to your ServiceNow instance.
Remember: Lack of access to your ServiceNow instance is not the excuse to not follow the regulation and the reporting timeline.
Perform gap analysis and identify requirements that you are not compliant with, prioritize them for implementation…

View full post