DORA in practice: technical tools and challenges

We recently published the first part of the interview here. Today we would like to take a closer look at the topic of implementation, risks and tools. You can find more information on the requirements and implementation deadline here.

In practice, the expansion of the risk frameworks has already shown that there are some new requirements from DORA. In addition to analysing ICT risks, ICT service provider risks and the expansion of existing risk frameworks must also be taken into account. To what extent could technical tools provide support here in general or for GAP analyses, resource and action planning?
Thomas Bachner: Technical tools can help to map known risks in a model and identify new risks through continuous use in the course of analyses. In addition to risk identification and assessment, our tool also makes it possible to carry out a sensitivity analysis, for example, in order to prioritise action planning with regard to resources. This gives companies an insight into how the implementation of this or that measure(s) can minimise an existing risk “xy” to an acceptable level. Continuous monitoring and improvement help to maintain compliance and also to keep an eye on and control the level of ICT security from a business perspective.

Which risks can be mapped in the process?
Thomas Bachner: Risks can be mapped based on ICT assets, IT processes, compliance with regard to the fulfilment of norms, standards and hazards (DORA, ISMS, ISO 27001, BCMS, NIS 2, …) and project management. This makes it possible to analyse all organisational, technical assets using predefined checklists/questionnaires (content libraries and knowledge packs), which are continuously updated in line with the state of the art. In addition to changes to technical assets, organisational, legal and normative requirements are also taken into account. In addition, corresponding reports and dashboards are developed and integrated for the various disciplines. This enables an all-encompassing risk management approach in accordance with DORA, including the recording and handling of ICT incidents, traceability of ICT security tests and the monitoring of central ICT service providers.

What challenges do you see? Practice also shows the challenge of maintaining an overview of the implementation of the individual articles and paragraphs, RTS and ITS of the DORA and tracking the implementation of measures using dashboards?

Thomas Bachner: The challenge for both sides is certainly answering the questions: As an affected company in the financial sector, can I manage all my ICT service providers with regard to the requirements of DORA? And as an ICT service provider, can or must I make changes in order to continue serving my customers affected by DORA? With our platform, we offer solutions for both sides in order to create clarity and maintain successful cooperation in the future.

We have developed a catalogue of requirements for the various chapters of DORA and incorporated them into our methodology. The questions on compliance with the articles were grouped thematically into modules. In addition, we also support compliance with the drafts of the Regulatory Technical Standards (RTS) and the drafts of the Implementing Technical Standards (ITS).

As a final word, a brief outlook on what you think companies can expect after the DORA implementation deadline

Thomas Bachner: The main challenge here will be to maintain the level, as there is a permanent process of technical change and a continuous process for ongoing compliance must be established, similar to ISO 27001. As a result, there may also be a need for a permanent officer in the company to drive forward general and interface issues, similar to the topic of data protection and data protection officers. In any case, DORA is an ongoing process that will continue after 17 January 2025.