DORA’s Next Round: What Financial Institutions Need to Know

The Digital Operational Resilience Act (DORA), initially published at the end of 2022, aims to strengthen the IT security of financial entities doing business in the EU such as banks, insurance companies, and investment firms. One of the law’s overarching goals is to make sure that the financial sector can stay resilient in the event of severe operational disruption by ensuring that connections between these firms and information and communications technology (ICT) vendors are secure and transparent.

However, not all of the policies outlining DORA’s regulations were published right away. The first round of rules largely focused on ICT and third-party risk management and incident classification. In July, the second and final batch of policies for DORA was published by the European Supervisory Authorities (EBA, EIOPA and ESMA), and they will be sent to the European Commission for adoption as the next steps toward finalization and enforcement.

Certa CEO Jag Lamba: “A slight reprieve” on some tasks, and clarity on timelines. 

With not much time between now and when DORA is set to come into force and financial institutions are expected to comply – January 17, 2025, assuming no delays in the planned timeline – let’s dig into the newly outlined policies and what they mean for banks, insurance companies and investment firms.

First Round In Place

To put the update in the proper context, let’s quickly recap what DORA rules were already in place. The act stipulates that companies must have a “sound, comprehensive and well-documented ICT risk management framework” that includes:

• Contract management capabilities defining roles and responsibilities in ICT vendor contracts, including stipulations around subcontracting.

• Vendor registries that stay up-to-date and detail contractual obligations.

• Due diligence procedures to assess vendor operational resilience, both before contracts are signed and repeated via routine reviews and monitoring.

• Incident reporting in a timely manner to relevant authorities after any disruption.

• Regular testing for third-party risk management (TPRM) procedures to simulate dangerous scenarios and test responses; formal audits may also be necessary.

• Business continuity plans in case of vendor failure so that the organization can continue business with minimal disruption.

The July Update

Here are the seven policy documents published in July, along with an overview of their impact:

• Joint Technical Standards on major incident reporting
  
  • The time limit for the intermediate report is still 24 hours, and for the final report still 72 hours, but that window is extended due to now “starting the calculation of the timelines from the submission of the previous notification/report, instead of the moment of classification of the incident as consulted.”
  • Weekend and bank holiday reporting is less stringent, with a reduced scope of incidents requiring reporting, fewer obligations for smaller financial entities, and extended time limits for notifications and reports.
  • The incident report is streamlined significantly, from 84 reporting fields to 59.
• Joint Regulatory Technical Standards on the harmonization of conditions enabling the conduct of the oversight activities
  • This document discusses information designated as “critical” when it is being provided by a third-party ICT partner.
  • It further details relevant identification codes and the scope and content of what must be furnished by these third-party providers to the lead overseer.
  • This includes subcontracting information and assessments of risks as determined by authorities.
• Joint Regulatory Technical Standards specifying elements related to threat-led penetration tests 
  • Changes to the way it’s determined whether or not financial institutions are required to perform threat-led penetration tests (TLPT) by default.
  • More clarity on TLPTs that involve several financial entities and/or ICT providers and the processes that require cooperation with authorities.
  • Additional flexibility on the requirements for testers, both internal at a financial organization or external, and threat intelligence provider.
• Joint Regulatory Technical Standards on the criteria for determining the composition of the joint examination team
  • This document covers the detailed criteria for determining the composition of the joint examination team – the structure involved in the daily oversight of the critical ICT service providers (CTPPs) – notably their designation, tasks and working arrangements to ensure consistent and efficient supervision.
  • The aim is to ensure a balanced participation of staff members from the European Supervisory Authorities and relevant competent authorities; ultimately, the ESAs are responsible for ensuring that ICT third parties are acting in responsible ways.
• Joint Guidelines on oversight cooperation
  • Details procedures and conditions for the competent authorities (CAs) and ESAs, including details on the exchange of necessary information.
  • This will help coordinate the oversight approach and keep overlaps and duplicating directives to hinder the monitoring of critical ICT providers’ risks.
• Joint Guidelines on the estimation of aggregated costs/losses caused by major ICT-related incidents 
  • These guidelines specify the approach financial entities must use when classifying ICT-related incidents as they assess gross costs and losses, as well as financial recoveries of such incidents.
  • Only “major” incidents for which the financial entity has provided a final incident report should be included when aggregating these numbers.

• Joint Final Report on the Regulatory Technical Standards for subcontracting 
  • This requires financial entities to specify whether subcontracting an ICT service that provides critical functions is permitted, and if so, any conditions that will apply.
  • Outlines requirements for the implementation and management of contractual arrangements on subcontracting conditions so that financial organizations monitor for risk the subcontractors that underpin their ICT services.

Many of these updates are either new guidelines that have been long awaited, since the original DORA guidelines left some gaps to be filled in, or revised specifics from the first round of policies. Indeed, the ESAs conducted several public consultations and invited responses from the organizations that would be affected by the policies of DORA to assess any potential changes.

In many cases, changes were implemented to initial requirements or processes, making it less cumbersome for financial organizations to report, test and communicate with relevant authorities adequately. While these changes don’t seem to change the core of DORA, nor what financial service companies should do to prepare for the regulations, they do seem to offer a slight reprieve from a few of the more time-consuming tasks associated with compliance, and more clarity around timelines and cooperations between entities.

Preparing for January

Given that the updates don’t represent a major course correction, the path forward for financial organizations preparing for DORA compliance by January 17 stays largely the same as it was since the first round of updates. Primarily, that means modernizing legacy systems to produce enterprise-wide visibility, scale operational resilience and enhance audit readiness. The following areas should be the focus of efforts going forward:

• Transparency: Collecting information from within the financial organization’s own systems and combining it with data gathered from third parties in an easy-to-analyze manner is crucial in advance of reporting to authorities. Vendors that can quickly furnish DORA-required data and provide audit trails should be prioritized in the coming months over the ones that are unable to gather the legally required information in a timely manner. Further, data mapping capabilities will be important in the process of gaining visibility into what data is currently available and where there are gaps. Identifying disruptions when they happen, and then managing them properly, is a key component of effective transparency.

• Designate a point person or team: A single individual or small team to head up DORA compliance across the organization will help with all the small, moving pieces involved. If that team spans multiple disciplines, all the better. The due-diligence requirements for DORA touch on multiple areas such as cybersecurity, vendor management, contracts, risk management and more. Building in a process for gathering information from these disparate parts of the company will help when it comes time for regular reporting or incident response.

• Roll out audit and testing capabilities: DORA requires specific frameworks for penetration testing (and this latest update provided more clarity on those processes), so it is time to put in place the capabilities to perform those tests with a relevant external provider. Similarly, DORA regulators will require proof of compliance, which means financial services providers should look for their third-party management systems to provide audit capabilities that cover not just their own organization’s suppliers, but their sub-suppliers as well, and store that information in a place where it can easily be accessed for reporting.

• Contract management: DORA specifies contractual clauses to be included in agreements between financial entities and ICT providers. These cover areas such as service descriptions and service level agreements, termination rights, audit and access rights (i.e. inclusion and enforcement of right-to-audit clauses), data handling and security requirements, and exit management and transition assistance.

Detail-oriented folks (given that we’re talking about the financial institution field, that should mean all of us) can read the full policies published in this latest round on the European Banking Authority website here and here.

Jag Lamba is founder and chief executive officer of AI-driven, third-party management platform provider Certa.