DORA – Delta View

Key Facts

• Previous BaFin supervisory objects are well equipped for DORA, new DORA supervisory objects face major tasks
• New for BaFin supervision objects are 24 requirements from the directive text and for all DORA supervision objects 19 RTS as well as 2 ITS
• Requirements for penetration testers prefer external over internal testers
• Many RTS/ITS can be brought forward, waiting for final versions is not recommended
• Requirements can be bundled over time with RTS/ITS and resolved early

Introduction

In the future, DORA is to transfer national regulations in the area of financial market regulation into uniform, harmonised EU law. CORE has already outlined the nature, content, effects and recommendations in a first blog post on DORA. This blog post is a supplement to the first and focuses on the delta to the current regulation, i.e. what is actually new for the established financial industry from DORA.
DORA expands the scope to about 20 types of companies and ICT third party providers1. For those companies for which the rule contents such as ICT risk management, reporting of ICT incidents and auditing of digital operational stability were previously not an issue, everything is new from DORA. For the companies already supervised by BaFin, such as credit institutions, financial services institutions, payment institutions and e-money institutions, insurance companies, securities institutions and capital management companies, DORA contains many parts that they already have to fulfil from other regulatory standards (see Figure 1).

Figure 1: Special audit in financial companies - legal basis and new object of supervision ICT third party providers

Other regulatory standards known to the aforementioned group are the IT Security Act 2.0 with the two central requirements "minimum security of technical-organisational equipment" and "reporting system for serious security incidents" (only for systems considered KRITIS), the Financial Market Integrity Strengthening Act (FISG) with provisions on the notification requirement for material outsourcing, the PSD 2 for payment service providers with the RTS for increased security requirements in online payment transactions and the Business Secrets Act (GeschGehG) in the event of claims for damages from successful attacks. The entirely new parts will be discussed in the follow-up.
The new requirements are fed from two sources: the text of the regulation and the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS). The RTS and ITS are also components of the regulation, but due to their later completion they form a class of their own. DORA is expected to enter into force at the turn of 2022/23, with the RTS/ITS following 12 to 18 months later. The application of DORA follows two years after its entry into force, so that the supervisory objects will have 6 to 12 months to implement the published RTS/ITS.

2. Need for action from the text of the directive

In Figure 2 all requirements from DORA are compiled that are new for the supervisory objects from XAIT2 and MaX3 already supervised by BaFin - in short: "DORA-Delta". A detailed tabular list of the DORA delta can be found in the appendix.

Figure 2: Delta from DORA draft of 23.06.2022

3. Need for action from RTS / ITS

Figure 3 summarises all RTS and ITS resulting from DORA. All RTS and ITS will be finalised by ESA 12 to 18 months after DORA enters into force, so in theory the oversight objects cannot start implementation until these final versions are available. But bringing forward various RTS and ITS is possible and necessary.

Figure 3: Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) resulting from DORA

Those technical standards that supervisory objects must already have in the field today should at least be updated, or if not adequately available, brought up to a legally compliant level. This includes all seven RTS from Article 14, because the existing BaFin supervisory objects from XAIT and MaX have to deal with the protection of confidentiality, integrity and availability (CIA) anyway, and all new supervisory objects from DORA have to do so for their own sake. For all new components from these RTS, such as the content and form of the report on the review of the ICT risk management framework, lobbying in the form of making one's own industry, sector, country-wide or even European coordinated drafts available to the ESA is a good idea, so that the "surprise" when the RTS is presented by the ESA remains as small as possible.
The same applies to the three RTSs from Article 16 around serious ICT incident reports and the one RTS and the one ITS from Article 18 on serious ICT incident reports: firstly, they all have to act on incidents and secondly, the criteria to be elaborated should be sent to the ESA beforehand as an agreed discussion proposal. In this double sense - own implementation and lobbying for a preferably Europe-wide, but at least nationally harmonised discussion proposal to the ESA - all other RTS and ITS from Figure 3 can also be seen in this light.
Supervised entities can already prepare for the RTS from Article 23(4) on penetration testing, as the regulation favours the TIBER-EU testing regime, which is known and understood. Only the requirements for internal testers could bring surprises from the RTS, so that apart from securing external test capacities, internal test resources continue to do their day's work until the RTS.
Registers with contracts with outsourcing companies are also known, so that only an adaptation to the specified format is required here for the RTS from Article 25(10). The policy on the use of ICT services required by Article 25(11) should already be a component of an ISMS and should not pose any major hurdles for existing supervisory objects. This should also apply to the detailed description of all functions (Article 27(4)) of the outsourcing company, otherwise things would already be going wrong in the contracts between the BaFin supervisory object and the hypersca-ler. With the voluntary application of the ICT third party provider to be included in the list of ICT third party providers to be supervised (Article 36(1)(a)), the third party provider can only apply after the corresponding RTS has been published. This also applies to the last three topics 19 to 21 from Figure 3: Adaptation to the legal text only makes sense once the RTS has been published.

4. Recommendations for action for previous supervisory objects

In Figure 4, the RTS/ITS "1" to "21" from Figure 3 are assigned to the requirements from DORA regulation text "A" to "X" from Figure 2 and plotted together over the time axis. The assumed date of entry into force of DORA is 1 January 2023. In the event of a later date of entry into force, the completion dates of the RTS/ITS are shifted accordingly, but their latest completion dates are already fixed at 12 or 18 months after the entry into force of DORA. Two years after entry into force, DORA will be applied, i.e. with the assumption made, on 1 January 2025.
The 21 RTS/ITS are accompanied by Figure 4 two further "deadline matters" 22 and 23 from the text of the directive. Although these are not RTS/ITS, they contribute to their further concretisation:

• 22: Article 10(9a): Common guidelines of the ESAs for estimating the aggregated annual costs and losses referred to in paragraph 9.
• 23: Report from Article 19 (1) in conjunction with (3). Para. 3: Report on the examination of an EU platform for serious ICT incidents

Figure 4: Merger of directive articles and RTS/ITS over time axis

From Figure 4 the possibility of combining the requirements from the directive text and RTS/ITS becomes crystalline across the time axis, so that the work on conformity with DORA can be bundled and thus better distributed in terms of time and organisation. A consideration at group level opens up spaces of focus.

Group A, B, D:

• A: Timely engagement with the philosophy, systematics and anticipation of DORA for one's own organisation is critical for success
• B: Previous BaFin supervisory objects must have a fully comprehensive ISMS in operation anyway - check for up-to-dateness recommended
• D: Checking the option to outsource 2nd line can be done in advance

Group C, E, F:

• C: The digital resilience strategy includes all requirements of Article 14 DORA and thus 8 RTS - to be done in the context of the ISMS update
• E: Based on own definition Identification of legacy ICT systems and joint treatment in strategy from C)
• F: Information security policy to be derived from existing IT strategy and new strategy from C)

Group I, M, V:

• I: Defining the crisis management function in the operational business continuity strategy
• M: Determine function Implementer of the communication strategy in the operational strategy to continue business operations
• V: Exit plans and their testing embedded in the operational strategy to continue business operations

Group H, K:

• H: Preparation of ICT strategy for the continuation of business operations and its review along the guard rails from RTS 4 and RTS 5
• K: Specific obligations for secondary processing location for CSDs and central counter-parties along the guard rails from RTS 4 and RTS 5

Group U, W and X:

• U: Reporting of outsourcing/projects known from FISG, but RTS 16 and RTS 17 will impose new requirements
• W: ICT concentration risk assessment esp. difficult to prepare earlier without RTS 16
• X: RTS 17 will set new requirements for essential contract content

Group J, N, O:

• J: immediate lobbying against deadline matter 23 recommended; with RTS 12 and RTS 13 as well as deadline matter 22, the content and format of this notification will be prescribed
• N: immediate lobbying necessary; with RTS 12 and RTS 13, the content and format of this notification will be prescribed
• O: immediate lobbying necessary; with RTS 12 and RTS 13, the content and format of this notification will be prescribed

Group P, Q, R, S:

• P: Elaboration of the testing programme must start immediately, RTS 14 will detail penetration tests
• Q: Elaboration of procedure for sufficient equipment with external and, if planned, also internal test capacities; elaboration of testing on live systems, early securing of test capacities recommended
• R: Selection and securing of the testers with the inclusion of RTS 14 - but orientation to TIBER EU already now possible and recommended
• S: Decide whether internal testers still make sense in the light of the requirements.

Single deltas:

• G: Connect anomaly detection with RTS 3
• L: Reporting of lessons learned does not require premature action
• T: Link strategy for risks from ICT third-party providers with specifications on multivendor strategy from RTS 16; RTS 15 will structure the contract register

Conclusion

All in all, both the existing BaFin supervisory objects and the new DORA supervisory objects cannot afford to wait for the completion of the RTS and ITS by the ESA towards the end of 2023 and towards the middle of 2024. Rather, both groups must start preparing for them now. Then, firstly, they have the chance to remain legally compliant and, secondly, on the basis of their les-sons learned from DORA, they can submit discussion offers for individual RTS and ITS to the ESAs in good time in order to still be able to influence the design of details in governance and organisation of their digital production base.
DORA will broaden the supervisory framework to about 20 types of companies, finally putting Europe's focus on the most important resource for prosperity and creative freedom in an over-complex world - the digital infrastructure. Financial companies and ICT third parties are the starting point for a modern, automated supervisory practice. Other important sectors will follow.