Increased security requirements across the EU financial sector

DORA implemented = well protected against attacks?

With the implementation of DORA, most financial companies believe they are well positioned to protect themselves and their business processes in the event of a cyberattack. However, this assumption is too short-sighted, as it ignores the management of future changes, which must ensure operational resilience in the long term. 

Managing change with DORA

(H2) Managing change with DORA

At the time of the DORA as-is survey, some very large projects were being set up in the financial companies in order to take a closer look at existing and potential future risks. As a result, measures were derived and described with which these risks can be avoided, mitigated, transferred or spread.

The DORA Regulation specifies in particular detail how companies must protect themselves against service provider failures. This was prompted by a series of cyberattacks in the form of data encryption attacks (ransomware), which led to considerable economic damage, as many service providers are dependent on the same central infrastructure.

These processes are generally well established for new acquisitions. In particular, outsourcing management plays a key role. However, it is worth taking a closer look at the change processes, especially when companies use cloud services such as SaaS (Software as a Service), IaaS (Infrastructure as a Service) or PaaS (Platform as a Service). The key question is then: how do companies recognize changes in these services that could entail risks early enough? After all, these services are not directly within their sphere of control and changes are not automatically noticed and therefore not assessed in terms of the hidden risks.

In this context, DORA demands strict testing of every change before it goes live. Companies must ensure that risk changes are identified and evaluated at an early stage.

If the scope of services used changes over time, new risks may arise. These must be identified before a service continues to be used or is used again. However, complete identification of all relevant changes is often more complex than it seems at first glance.

Examples:

• When a department uses or changes software independently without the IT department being involved.
• If a service provider merges or replaces subcontractors, existing emergency plans no longer work as planned.
• If a change creates new threats to IT security that require an immediate risk reassessment.

It is therefore essential that all organizational units work closely with risk management. Quarterly reporting is no longer up to date – instead, risk management must be directly linked to change management in order to be able to react continuously to new risks. In the following, we explain some everyday scenarios whose implications for risk management only become apparent on closer inspection.

DORA change management: business and control

An HR application from a service provider (topic to be considered: Third Party Risk) is initially introduced for purposes that are owed to a normal administrative act and can be classified as justifiably outsourceable in terms of confidentiality, availability and integrity risk – for example, employee time tracking. At this point, the risk analysis is typically carried out for those parts of the application that are intended to be used at that time. 

However, the application has a much stronger tool potential and allows a lot in terms of use, so that the processes carried out in daily use are constantly being expanded. For example, employee meetings are now also to be logged. This data is generally classified as strictly confidential because sensitive or critical content could be recorded. From a risk management perspective, a "change request" is required even though no technical changes are made. And this is before the application is put into extended productive use. 

This one example clearly illustrates the need for close cooperation between different organizational units with regard to risk management: Compliance has defined processes that make such risks visible, e.g. service management in accordance with ITIL. In this process framework, the specialist department (Fachbereich) reports the desired change in use, according to which data protection can reclassify confidentiality and risk management can request additional measures to protect the data from the service provider. Governance checks the economic efficiency, Legal checks contractual rights, Purchasing adjusts the contracts and changes, if necessary, the monitoring measures for the service provider. Due to the increased risk, additional tests are introduced in the specialist department (Fachbereich) and IT. 

DORA change management: IT and risk management

An external data center that manages the data of a financial company is thoroughly checked during the purchasing process and contracted with the conviction that it is secure. The checks are carried out regularly. However, every financial company must be aware that such data centers are repeatedly and often the focus of attacks, as the damage is multiplied by the number of users of such a service. It is therefore essential from the point of view of emergency preparedness to be able to switch from one service provider to another if a service provider gets into difficulties. 

Let's take as an example the contingency plan that in the event that the data of the data center operator were encrypted, the data could be displayed at another data center operator. Until the problem is resolved! This can sometimes take several weeks, as the attackers usually encrypt in such a way that importing a data backup also means importing the encryption. Fixing such a problem often takes so long because the actual information first has to be separated from the malicious information, as this has been hidden by the attackers and the search is always not easy.

Another good example is that of a sick customer from the insurance industry who has applied for an operation at this very moment and is waiting for approval of the costs. In the case of an urgent operation, he cannot wait long for this approval. However, the insurance company cannot make a blind cost commitment either. And the customer cannot or does not want to pay for the operation out of their own pocket. An operation can easily cost 15,000 euros or much more. What is the fate behind this financial decision?

A financial institution likes to prevent this by securing the data with a suitable stand so that this data can be processed on an interim basis by the same or better another service provider whose infrastructure was immune to this encryption.

DORA change management: legal and compliance in the portfolio

By the deadline of January 17, 2025, most institutions have had their DORA project completed and meet the legal requirements. However, there are many uncertainties as to whether they will continue to do so in a year's time and beyond. How will the company develop? And will they continue to do so in a year's time and beyond? Which impact will any changes have on DORA compliance? Legal and Compliance must be able to assess the context of changes and their impact on DORA. To this end, they now work more closely with the specialist departments than ever before. A department cannot think in silos; many changes take place across departments. This is why it is now sensible and essential to have established reporting and decision-making channels in service processes (law, review, decision). To avoid getting lost in too much work, it is possible to use automatic checks. This allows all parties involved to concentrate fully on checking the real implications from a legal or compliance and governance perspective. Changes based on legal assessments belong in a portfolio and therefore compete with other projects. These resources must be kept free, as legal issues have top priority in most companies. Incidentally, this should also be implemented outside of DORA, as it applies in principle to all possible laws and regulations.

DORA change management: Efficient management of risks

Risk management plays the main role in DORA. It is expected that there are clear processes in place to manage every relevant risk against digital resilience in risk management. In other words, from an everyday professional perspective: You can no longer get away with a reporting system based on Excel. From this starting point, it at first sounds like a lot of work. However, much of it can be automated, such as the evaluation of existing knowledge in the systems. For example, risk management can use automated reports to discover a server that (inadvertently) not has received any security updates. Automation also increases reporting quality and speed. An insecure server is usually not only a danger to itself, but also to the surrounding systems. This seemingly small risk could bring entire process chains to a standstill. This is why DORA is often started with a review of all process documentation, which plays a major role in assessing a risk.

But DORA also saves money, not just costs it. For example, it is much more economical to counteract damage associated with a risk than to wait until a risk occurs. Repairing the damage often costs ten or a hundred times as much. So even if the probability of occurrence is low but the damage is very high, the relatively inexpensive measures for risk avoidance, risk reduction or risk mitigation are worthwhile.

Risks can be reduced also with the motto "Always test before going live", the effect of which is often underestimated. This topic is primarily aimed at identifying risks earlier, i.e. before they become productive. 

DORA is committed to putting information and communication technology through its paces with a risk-based, proportional testing program. 
In addition, all financial companies are audited again by a higher-level body, with the main purpose of helping to identify risks and thus ensure the resilience of financial companies throughout Europe. But what is being tested is the added value that companies are now creating: Digital resilience.

DORA change management: control as a supervisory board or management board

As the Supervisory Board (Aufsichtsrat) and Management Board (Vorstand) play a central role in the governance and monitoring of DORA compliance, structured risk management is crucial. Efficient implementation requires automation, targeted portfolio management and clear monitoring mechanisms to ensure that processes remain resilient and governance is proven to work without being overly burdensome.

The introduction of DORA was an important milestone, but the real challenge lies in the continuous monitoring of daily operations and, in particular, daily change management. How can the Supervisory Board ensure that risks are identified and addressed in real time?

Examples of typical control issues of a supervisory board or management board:

• How is it ensured that all changes in IT systems and third-party services are systematically recorded, evaluated and approved?
• Are there automated monitoring mechanisms to detect new ICT risks in real time?
• How is reporting to the Management Board or Supervisory Board carried out? 
  Are the indicators and KPIs for DORA risks prepared in a transparent and comprehensible manner?
• Which processes come into play when a service provider changes or new regulatory requirements arise?

These control issues show that DORA is not a one-off compliance project, but an ongoing management task that requires a clear allocation of responsibilities and stringent controls.

When will I be finished with DORA?

At trendig, we have extensive experience in the design and optimization of the processes outlined above and can support German banks, insurance companies and financial service providers in ensuring that DORA compliance is not just formal evidence but is developed into an integral part of corporate management in order to achieve digital resilience.

In the following, we would like to briefly outline some of the main ideas that we at trendig believe should be an essential part of your DORA compliance efforts. 

Resilient ITC systems to minimize risk

One of the key measures for reducing ICT risks is the establishment and maintenance of resilient ICT systems and tools. These must be designed in such a way that they minimize security vulnerabilities and are resistant to threats. Resilient IT infrastructures make a decisive contribution to ensuring operational stability and reducing the risk of failure.

Identification and classification of critical functions and processes

Effective risk management requires critical key functions and processes to be identified, classified and documented. Without a detailed record of these elements, targeted control and prioritization of security measures is not possible.

Continuous monitoring and reporting systems for ICT risks

Continuous monitoring of all sources of ICT risks is crucial in order to identify potential threats at an early stage and implement suitable protection and prevention measures. A reporting system for identified security vulnerabilities must be established for almost all services in order to enable a rapid response to new risks and minimize attack surfaces.

Automated and documented risk communication

Furthermore, cross-line, automated and recorded communication about changes to significant risks is essential. Relevant stakeholders in the fields of data protection, information security, risk management, IT, specialist departments, legal, purchasing and the Management Board must work closely together in order to assess risks at an early stage and coordinate appropriate measures.

Complete testing before changes go live

Before changes to software, hardware, infrastructure or services are put into productive operation, complete testing is essential. This applies not only to new implementations, but also to existing systems in order to minimize the risk of undetected vulnerabilities.

Real-time monitoring with immediate reporting capability

Comprehensive 24/7 monitoring is required to detect anomalous activities and ensure that IT security incidents are reported immediately. Effective incident response management can only be guaranteed if security problems are identified and escalated quickly. 

Business continuity policies and contingency plans

The introduction and regular updating of business continuity guidelines as well as emergency and recovery plans is essential for operational security. Annual tests of these plans ensure that all necessary functions remain functional in the event of an emergency and that crisis scenarios can be managed efficiently.

Risk management for service provider dependencies

A critical point in risk management is recognizing the impact on emergency plans when framework conditions change. This is particularly relevant in the case of dependencies on service providers and sub-service providers, as contingency plans often depend on their stability. Companies must ensure that all partners involved also have robust contingency strategies in place.

Learning mechanisms from internal and external incidents

The continuous improvement of IT security requires the establishment of mechanisms for analyzing and evaluating external and internal ICT incidents. Companies must learn from past security incidents in order to continuously develop their protective measures and recognize future threats at an early stage.

Frequently asked questions about DORA