DORA : How the financial sector strengthens its capabilities in the face of crises?

Teaching from the Latest Publications of Regulators

The European regulation DORA (Digital Operational Resilience Act), published in January 2023, comes into effect on January 17, 2025. Its aim is to enhance the digital operational resilience of actors in the financial sector: anticipating, preventing, responding to, and recovering from digital incidents, all while ensuring the continuity of essential activities.

In order to guide stakeholders and specify requirements, the European Supervisory Authorities (ESAs) have developed a set of 14 Regulatory Technical Standards (RTS) and Implementation Technical Standards (ITS), published in two batches. The final version of the first batch was released in January 2024. The second batch, focusing on key chapters of the regulation such as testing, was published on December 8, 2023. It is open for public consultation, undergoes discussions with financial sector stakeholders, and will be validated by the European Commission in July.

Here, we analyze the main topics covered and draw lessons from this second batch, focusing on three major challenges:

Less than a year before the implementation date of DORA, financial entities must already take into account this draft of batch 2 to refine their compliance projects.

Clarifications in the final version of the batch 1 of RTS/ITS have provided more flexibility and proportionality to the requirements (including the possibility of not necessarily resorting to encryption solutions to contribute to ensuring the Confidentiality, Integrity, and Availability (CIA) of data – we will address these aspects in more detail in a future article dedicated to batch 1). We can also expect certain developments/clarity in the final version of the batch 2 of RTS/ITS.

Threat-Led Penetration Testing (TLPT)

An ambitious framework to challenge the capabilities of critical IT systems to withstand cyber attacks.

Who is affected? Most financial entities.
Systematically affected: central counterparties, central depositories, and credit institutions recognized as globally and systemically important; Financial entities exceeding a certain threshold in the previous 2 financial years:

€120 billion in payment transactions for payment institutions.
€120 billion in payment transactions or €40 billion in circulating electronic money for electronic money institutions.
€500 million in gross premiums for insurance and reinsurance institutions.
The largest market share nationally or 5% at the European level for trading platforms.

The regulator will consider the risk profile of the entity, the complexity of the ICT architecture, and the degree of dependence of important or critical functions on ICT systems. The aforementioned entities may not be required to conduct TLPTs if the assessment of certain criteria indicates that it is unnecessary in terms of factors such as financial stability and ICT risks. Conversely, the authorities responsible for TLPTs may decide to include entities that do not meet the mentioned criteria.

The frequency of conducting tests and the involved stakeholders are already specified:

Article 26 mandates financial entities to perform a Threat-Led Penetration Test (TLPT) at least every 3 years, covering the IT systems that support critical or important functions.
Article 27 specifies that testers must possess the necessary technical and organizational capabilities and demonstrate the required expertise. The use of internal testers must be approved by the relevant competent authority, and the threat intelligence provider must be external to the financial entity.

However, it remains unclear whether each financial entity will be required to test all of its critical or important functions in each testing occurrence.

How will the TLPTs unfold? Four "colored" phases involving White, Blue, Purple, and Red teams:

Preparation - Key phase in coordination with regulators (White Team)

Regulatory authorities (ACPR, Banque de France, etc.), gathered within the TLPT Cyber Team (TCT), validate the TLPT scope proposed by the financial entity. The entity will designate individuals to lead and oversee the proper execution of the test.

Note: TCT must approve the selection of providers chosen to conduct penetration tests and threat analysis. If the chosen providers are rejected, the TLPT cannot receive approval at the end of the exercise.

Threat Analysis (Red Team - Threat Intelligence)

The Threat Intelligence team analyzes threats, develops attack scenarios, and transmits them to the Red Team. This phase will last 4 to 6 weeks, depending on the scope validated by the White Team and TCT.

Penetration Testing (Red Team - Penetration Testing)

For at least 12 weeks, the Red Team conducts intrusion tests on production IT systems without internal support and without notifying the internal security team (Blue Team). The objective is to achieve the missions set by the Threat Intelligence team without being detected. Detection of the Red Team does not end the exercise. It must be reported to the Red Team, which will change the attack scenario. In case of failure, the Red Team may use predefined advantages from the Threat Intelligence team to ensure the realism of the exercise and train the entire spectrum of the financial entity’s teams.

Resitution: Replay, Purple Team, and Approval

Following the tests, the Red Team delivers its comprehensive report to the White Team and TCT. Replays are mandatory to verify certain scenarios prevented or not prevented, detected or not during the testing phase. They can take various forms: crisis exercises, Purple Team, blind replay, etc. TCT will issue the TLPT completion certificate at the end of this phase.

Details are awaited on the deadline for conducting the first TLPT, the composition of Purple Teams, and the selection of the decision-making entity for TLPTs conducted on a group scale.

Who bears the responsibility for the tests? In all cases, the financial entity is fully responsible for the execution of the TLPT

The RTS imposes constraints on the use of internal testers, including:

Defining a policy for the management of internal testers.
Establishing measures to ensure that the use of internal testers has no negative impacts.
Implementing measures to ensure that internal testers have the resources and skills necessary to conduct TLPTs.

DORA relies extensively on the TIBER Reference Framework

The European TIBER framework (Threat intelligence-based Ethical red-teaming) EU, published in 2018 by the European Central Bank, aims to enhance the resilience of financial entities against cyber-attacks. TIBER-EU, transposed into TIBER-FR in January 2024 to address national specificities, provides a set of practices for conducting cyber-attack simulations on the critical functions of the entities involved.

The duration of a TIBER-FR engagement is approximately 6 to 9 months (triennial cycle). The durations mentioned in the diagram below are averages and provided for indicative purposes.
The same teams are involved; only their designations change for three of them: the Control Team becomes the White Team, the TPLPT Cyber Team corresponds to the TIBER Cyber Team, and finally, the testers are referred to as the Red Team.
Despite strong similarities between RTS TLPT and TIBER-FR, two differences are observed: in DORA, a Purple Team must be included in addition to the Red Team, and it is allowed to use internal auditors to form the Red Team.

Third-Party Risk Management (TPRM)

Special attention to risks associated with third parties.

In a context where financial entities increasingly interact with third parties, Third-Party Risk Management (TPRM) is emerging as a crucial element of corporate governance. The use of information technology has become central in delivering financial services. However, the provision of IT services often relies on a complex subcontracting chain where third-party suppliers may enter into one or more subcontracting agreements with other providers. This reality creates a situation of dependence for financial entities on IT subcontractors.

In this context, DORA requires financial entities to make every effort to identify and monitor all subcontractors providing an ICT service and in particular third parties supporting critical or important functions. In order to build resilience in the event of the failure of a critical third party, DORA requires financial entities to formalise and then test exit strategies. The aim of these exit strategies is to enable financial entities to ensure the continuity of their critical functions in the event of a breakdown in the relationship with a third party operating on these functions.

A contractual alignment to anticipate as early as possible #ContractualRemediation
The EBA guidelines on outsourcing had already called for a review of ESPP contracts; with DORA, these obligations are taken up and completed for all third parties providing an ICT service. Article 30 requires contracts to include a clear and comprehensive description of all ICT functions and services to be provided by the service provider. In addition, other regulatory requirements could be included in the clauses to facilitate compliance (security requirements, tests, controls and auditability, etc.).

Article 30 mandates the inclusion of a clear and comprehensive description of all functions and IT services to be provided by the service provider in contracts. Due diligence procedures ensure the ability to select and assess the operational and financial capabilities of third parties.

The third party ICT service provider has adequate capacity, expertise, financial, human and technical resources, applies appropriate information security standards and has an appropriate organisational structure, including risk management and internal control, incident reporting and response, to monitor its subcontractors.
The impact of a subcontractor’s failure on the provision of ICT services supporting critical or important functions must be controlled.

Intragroup subcontractors are considered service providers under DORA and must, therefore, be included in the contractual remediation process.

Enhanced controls before subcontracting decisions of critical activities

Financial entities must conduct a risk assessment to substantiate all outsourcing decisions. Among the risk elements specified by the AES supervisory authorities, the following are included:

The location of the IT subcontractor or its parent company
The number of IT subcontractors
The nature of data shared with IT subcontractors
The location of data processing and storage
The potential impact of disruptions on the continuity and availability of IT services supporting critical or important functions provided by the third-party IT service provider
The assessment of the difficulty of reintegrating the outsourced service into the company
The risk of concentration

The financial entity evaluates the subcontractor for:

Its business reputation
Its resources (including expertise and financial, human, and technical resources)
Information security
Its organizational structure (including risk management and internal controls that the subcontractor must have in place).

A precise framework of requirements before allowing third parties to subcontract themselves

To mitigate risks associated with subcontracting throughout the contract lifecycle, contracts must specify the conditions under which the provider may engage subcontractors. The financial entity must have the right to terminate the agreement with the third-party IT service provider in the following two cases:

Reporting & notification of major incidents

Financial entities must record all incidents related to ICT and significant cyber threats. They ensure monitoring, processing, and follow-up of ICT-related incidents to ensure that root causes are identified, documented, and addressed to prevent such incidents from recurring.

When a major ICT-related incident occurs and impacts the financial interests of clients, financial entities inform their clients without undue delay once they become aware of it. The measures taken to mitigate the negative effects of this incident are also shared. In the case of a significant cyber threat, financial entities inform potentially affected clients of any appropriate protective measures they may consider taking.

Chapter 3, concerning incidents, has just been supplemented by an RTS and an ITS aimed at specifying the templates (ITS), deadlines, and modalities (RTS) for reporting major ICT incidents and the voluntary reporting of significant cyber threats.

Notification deadlines for incidents aligned with the NIS 2 Cyber Directive

These RTS/ITS complement Article 19(4) of DORA, which requires financial entities to submit three incident notification reports: an initial notification, an interim report, and a final report. The deadlines for reporting major incidents align with the NIS2 Directive (Directive on the Security of Network and Information Systems):

Precise information about the nature and significance of the incident to be reported to the regulator
Financial entities are required to refine their reporting as they gain control over the incident.

Initial notification

The date and time of incident detection, its description and source, classification criteria, impacted Member States, impact on other entities, recurrence, and activation of the business continuity plan.

Interim report

Incident reference code and type, date and time of occurrence, recovery details, classification criteria, affected areas and processes, infrastructure details, communication actions, reporting to other authorities, and actions taken.

Final Report

Root cause, legal compliance, breach of contractual agreements, date and time of resolution, resolution measures, reclassification, information for resolution authorities, as well as cost and loss details.

In parallel with this incident reporting, the text provides for the notification of significant cyber threats: date and time of threat detection, threat description, potential impact, classification criteria, threat status, and actions taken.

The regulator provides declaration templates to standardize notifications
The templates include 101 data points, with mandatory essential fields (46) and conditional fields, depending on the nature of the incident.

Thank you to Céline TERRIEN, Cassandre HENAULT, Constance RAGEOT, Estelle BONNET, Pierre LE PIRONNEC, Lucas FAUCHER, Antoine STOEV, Esther REISS, and Tatiana QUINTERO DEDIEGO for their contributions.