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

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.

1. Identify which type of financial entity your organization is, select the requirements that apply to it.

2. 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.

3. Identify inventory of services that your organization offers and whether their business criticality is maintained.

4. Translate thresholds % into absolute numbers in your organization, do you have a mechanism to count it?

5. 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.

6. Embed the new 3-stage reporting obligations and their due dates into major incident communication plans, identify responsible colleagues.

7. Engage with the compliance team and internal audit that will validate the compliance readiness.

8. 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…