Today is 17 January 2025 and the party can begin: as of today, full compliance with DORA, the Digital Operational Resilience Act, is required. The invitation to this party was sent exactly two years ago, when DORA entered into force. Since then, all the decorations have been put up in the form of Regulatory Technical Standards (RTS), and supervisors have indicated which slice of the cake will be served first: the registers of information. In this blog, I will walk you through the key points at a high level, so that you can arrive at the DORA party well prepared.
The invitation
Who falls within the scope of DORA has been discussed extensively in recent months. The core idea of the Regulation is to make financial entities more digitally resilient. What qualifies as a financial entity is set out in Article 2(1)(a) to (t) DORA. This includes organisations such as banks, trading platforms and pension funds.
The final category that must take DORA into account is listed in point (u) of the same article: third-party ICT service providers. An ICT service provider is defined in Article 3(21) DORA as:
“Digital and data services provided on an ongoing basis through ICT systems to one or more internal or external users, including hardware as a service and hardware services, including the provision of technical support through software or firmware updates by the hardware provider, excluding traditional analogue telephone services.”
Throughout the recitals of DORA, the European legislator makes it clear that almost all IT suppliers to financial entities may fall within this definition. In its Implementing Technical Standard (ITS) on the register of information, the European Banking Authority (EBA) draws a helpful distinction between types of IT suppliers, which can assist in determining exactly what kind of ICT service a supplier provides. To stay within the festive metaphor: almost everyone is invited.
The decorations
The decorations that adorn DORA were already put up at the beginning of January 2024, when the first set of RTS and ITS was submitted by the European Supervisory Authorities (ESAs) to the European Commission (EC). The abbreviations come thick and fast. These are regulatory standards intended to ensure the proper implementation of policies, procedures and protocols. Many of these have already been published and adopted by the EC, but not all of them. On 17 and 26 July 2024, the ESAs submitted the second and final set of standards to the EC, which at the time of writing have still not been approved. These include the RTS on subcontracting and the reporting of major ICT-related incidents. It is therefore quite possible that further changes to the regulatory framework will follow after today, which must be taken into account when drafting DORA-proof contracts.
The cake
As mentioned in the introduction, the supervisors (the Netherlands Authority for the Financial Markets and De Nederlandsche Bank) will initially focus on the register of information required under Article 28(3) DORA. National supervisors must in turn submit these to the European Supervisory Authorities in April 2025 (recital 7 DORA). This leaves a relatively short period in which the registers of information must be delivered. In August 2024, De Nederlandsche Bank pointed to the earlier referenced ITS in the hope that everyone would get started promptly. This standard template is, however, a formidable document that many lawyers, compliance officers and CCCO®s have struggled through. Financial entities will each use their own model, most likely derived from the standard template. Every ICT service provider will most likely already have received one or more emails requesting completion of these templates.
The contracts
We now officially leave the party metaphor behind. It is difficult to maintain when discussing the contractual provisions on digital resilience that must be agreed with third-party ICT service providers. Where an organisation performs these services in-house, no such contracts are required.
Articles 28 and 30 DORA set out the contractual requirements in fairly straightforward terms. The first requirement typically addressed is a clear description of all functions and ICT services to be provided by the third-party ICT service provider. In most cases, these ICT services and functions will already be described in the existing agreement with the ICT service provider.
In practice, everything relating to DORA is therefore often set out in an addendum, such as the model developed by the Dutch Association of Insurers. Each supplier will understandably want such addenda to be amended so that they align properly with their organisation. Detailed knowledge of the statutory text and the RTS and ITS is essential in this context.
The provisions that follow are all intended to ensure the reliable and proper delivery of these functions and to give the financial entity more options if this is not the case. Many of these provisions are already included to some extent in existing agreements with ICT service providers, but the obligations under DORA go slightly further. A distinction is made between critical and non-critical functions, with stricter requirements applying to critical functions.
The definition of a ‘critical function’ is set out in Article 3(22) DORA:
“A function the disruption of which would materially impair the financial performance of a financial entity (…) or the failure of which would materially impair a financial entity’s continuing compliance with the conditions and (…) obligations under the applicable financial services law.”
In the context of DORA, this specifically concerns outsourced services provided to or by an ICT service provider that are of such importance to the financial entity concerned. For critical services, the additional contractual provisions are set out in Article 30(3) DORA and include, among other things, additional requirements relating to monitoring and audit obligations (point (e)) and exit plans (point (f)).
The control measures
One last metaphor, then: the afterparty. This can be found in the various control measures that financial entities and their ICT service providers are expected to have implemented. These measures are divided into five pillars: ICT Risk Management, Incident Management, Digital Operational Resilience Testing (TLPT), Third-Party ICT Risk Management and Information Sharing. For a concise explanation of these pillars, I warmly recommend our cheat sheet.
Enforcement of DORA will follow the enforcement policies of the AFM and DNB. This will initially involve informal measures, such as discussions, but administrative fines may also be imposed. As is common with European legislation, the amounts of such fines under DORA can be substantial. In short, there is ample reason for financial entities to have appropriate measures in place and to ensure that their ICT suppliers also have their affairs in order.
De Nederlandsche Bank expects financial entities to have their organisations fully prepared for compliance with DORA. To support this, conducting a gap analysis is recommended and knowledge sharing within the sector is encouraged. Carrying out such analyses, DORA quick scans or providing support across the five DORA pillars are areas in which ICTRecht can of course assist.
Does your organisation have to deal with DORA? We are happy to think along with you, so that the party does not fall flat.
