Where Should You Start with DORA Requirements?
DORA sets uniform digital operational resilience requirements across the EU for banks, payment and electronic money institutions, insurers, investment firms and other financial market participants. The regulation covers five main areas:
- ICT risk management,
- ICT incident management and reporting,
- digital operational resilience testing,
- ICT third-party risk management,
- sharing of cyber threat information.
With many requirements and limited resources, the speakers began with a practical question: how to implement DORA so that it is more than a formality.
Some organisations are still lagging behind with DORA implementation, noted Martynas Savickas, head of vCISO. His advice is to slice the ‘pie’ into three parts:
- ICT risk management.
- Relationships with third parties – providers of external services and their components.
- Business continuity – testing various scenarios, checking and improving recovery plans, identifying weak spots and strengthening resilience.
Only once these foundations are in place, he said, does it make sense to move on to strategy, controls and audits, and later to continuous improvement.
Why Are Critical Function Lists Getting Shorter?
DORA requires financial institutions to identify their critical or important functions and to map each function to the ICT systems and providers that support it. This list shapes almost all further work: business continuity plans, the scope of resilience testing and threat-led penetration testing (TLPT), stricter requirements for contracts with providers, and the register of information. How accurately it is drawn up therefore determines where an organisation will focus its resources.
As Zygeda Augone, Head of Information Security at Swedbank, explained, providers of services had lists of critical functions before, but they were very long. When DORA came into force, some organisations made them even longer. Over time they had to pin down what truly matters, and many organisations cut their lists significantly and set clear priorities.
The most important change is the realisation that not everything has to work all the time: 10–20 essential functions remain, while others can wait. ‘To understand this, you have to go through more than one incident,’ said Z. Augone. At some larger European banks, the lists shrank from more than 100 to around 20 functions.
TransferGo had a similar experience. According to Marius Bindokas, the company’s first list was also too long, as tight deadlines meant it was compiled in a hurry, without a thorough assessment. Later, the company carried out a business impact analysis (BIA) with all its departments and assessed, for example, whether a communication tool was really more important than the core business system. As a result, 2–3 critical functions were defined.
What Does TLPT Add to Red Teaming?
Red teaming is a controlled simulation of a real attacker’s actions. Testers try to reach a specific goal, such as gaining access to critical systems or data, and test not only the technology but also people, processes and whether the organisation detects and responds to the attack in time. It differs from a standard penetration test in that it does not just look for vulnerabilities within a predefined scope, but tests the entire chain of defence.
Many organisations claim they already do red teaming, but according to G. Vinciūnas, Head of Information Security at Baltic Amadeus, what goes by that name is often a standard penetration test that ends with a list of vulnerabilities in a report. There is a simple way to check: during the test, did anyone verify whether your security team noticed the attack and how it responded?
For the financial sector, DORA introduces a stricter form of this testing – threat-led penetration testing (TLPT). In essence, it is a controlled red team test, mandatory for the financial institutions designated by the supervisory authorities, and a completely new practice on the market. The main differences between TLPT and conventional testing:
- Threat intelligence. A threat assessment tailored to the organisation’s profile must be obtained from an independent provider.
- No choice of scope. The scope is assessed by the supervisory authorities, so all critical and important functions must be included in the test.
- Duration. Under the TLPT regulatory technical standards (RTS), testing must last at least 12 weeks.
- Frequency. TLPT is repeated at least every 3 years.
The market is already starting to adopt this requirement, but according to G. Vinciūnas, the three-year cycle has a drawback: the situation can change considerably in that time, so the results may no longer reflect reality. That is why it is worth running targeted red team or penetration tests regularly between TLPT cycles.
Asked whether artificial intelligence could replace penetration testers, G. Vinciūnas said that handing the entire assessment over to AI means losing the human input. It then remains unclear whether AI understands the organisation’s critical functions, and that is exactly what determines whether the testing covers what matters most to the organisation.
Third-Party Risk and the Register of Information
In practice, there have been several cases where a company’s internal systems worked flawlessly, but customers could not get the service because a third party’s infrastructure failed. In this context, a third party is an external ICT service provider that a financial institution relies on to deliver its services, such as a cloud service provider, a data centre, a software or payment infrastructure provider, as well as their subcontractors. The speakers agreed that DORA helps prepare for such cases but does not eliminate the risk.
The bigger the third party, the more services depend on it, so according to Z. Augone, you need plans A, B and C. It is important to know whether you have an alternative if one service fails, and what you do if, for example, payments are down while other systems keep running. Certificates and audits usually show the situation at a given point in time, whereas DORA provides the opportunity, or even the obligation, to test together with partners against complex scenarios. This helps strengthen the organisation’s resilience and build closer cooperation. ‘Do incident plans always work the way you want them to? No. But preparation helps shorten the response time,’ she said.
M. Savickas illustrated how heavy the dependence on a single provider can be with the example of Amazon Web Services (AWS): in October 2025, when cloud services were disrupted, not only the organisations themselves but also their partners were affected.
However, fully insuring against such cases can be expensive. Not every organisation has the resources of large banks, and full duplication, such as using the platforms of two different cloud providers, can cost millions and almost double operating costs. This is where the principle of proportionality comes in – decisions are made based on risk: whether it is acceptable to the business and how much it is worth paying to reduce it.
Accepting risk is inevitable, but it has to be clearly named, said M. Bindokas. If all data and infrastructure depend on a single provider, the organisation cannot be more resilient than that provider. That is why the IT manager responsible for DORA should openly inform management about such a dependency and about the fact that, in the event of a major incident, restoring systems could take up to three months. If the likelihood of such an event is very low, the risk may be acceptable. Moreover, procedures alone or people alone are not enough: ‘You can have people working 24/7, but without procedures and testing, all that preparation will come to nothing.’
The register of information is also directly linked to third parties. DORA requires financial institutions to list all their contracts with ICT service providers in it and to submit the register to the supervisory authority every year – this has been done twice in two years. According to G. Vinciūnas, the first submission was chaos for both financial institutions and the Bank of Lithuania. The second was somewhat easier, but the process remains complex, and most entities still treat the register as compliance ‘through gritted teeth’. Even so, preparing it turned out to be a good inventory exercise: many entities did not know where to find contracts or supplier contacts, even though these determine what can be demanded in the event of an incident.
The Role of the Board and Duplicated Requirements
DORA has brought potential ICT risks straight to company boards. According to Z. Augone, boards are now presented with more IT, information security and business continuity issues, dependency and concentration risks, along with incident reports and key performance and risk indicators. However, boards are usually made up of people who are not technology specialists, so risks and their impact need to be presented in clear business language.
The board’s job is not to look for risks but to make decisions about them, M. Savickas reminded. To do this on an informed basis, the board needs IT and AI competences, and specialists need to learn to speak the language of business: ‘When you present a technical problem in business language, you have a connection with the board members.’
TransferGo’s experience shows what this looks like in practice. According to M. Bindokas, vulnerabilities that were only partially monitored before DORA are now tracked daily, and a separate line has appeared in the board report: how many critical vulnerabilities were not remediated within the set timeframe. The target value is zero, and every deviation has to be explained.
Governance is further complicated by the fact that the same requirements are described several times over in DORA, the NIS2 directive, the ISO 27001 standard and internal policies. According to G. Vinciunas, chaos arises when each regulation is implemented separately – one goes to the finance department, another to IT. This leads to hundreds of documents with different rules, for example, four different password policies. It is important to find common ground, consolidate the requirements and appoint one person responsible for overall compliance implementation.
How Does DORA Really Increase Resilience?
Almost two years after DORA began to apply, it is becoming clear that the value of the regulation lies not in the number of documents prepared, but in how ready an organisation is for a real crisis. All the speakers’ answers shared the same idea: compliance is a consequence, not a goal.
Pursuing compliance for its own sake, in M. Savickas’s words, is merely ‘running away from fines at the lowest possible cost’. In his observation, organisations that took DORA seriously gained new capabilities and created more value for the business. According to M. Bindokas, regulations are essentially a collection of good practices, so the key is to show the business not only the cost but also the benefit. ‘We have been living with DORA for three years, and now people can see the benefits,’ he said.
The audit function matters, but as Z. Augone stressed, an organisation has to live resilience every day, and the financial sector is now raising the bar for its third parties as well. In G. Vinciunas’s view, resilience works when employees know how to restore a system, whom to contact in the event of an incident and what the company’s information security policy is – not when the organisation has hundreds of different documents that nobody has read.
We thank the speakers and the moderator for an open discussion and practical insights on this highly relevant topic for the financial sector.
