DORA in 2026: What fintechs and IT vendors need to know now

DORA is in effect, but the rules came in phases
DORA is intended to strengthen the digital operational resilience of financial institutions and make IT risks more manageable. On paper, that sounds like one uniform European framework. In practice, the introduction turned out to be a lot less tightly defined.
Indeed, an important part of the elaboration lay with the European supervisors, EBA, EIOPA and ESMA. They had to lay down detailed rules for various components, including ICT incident management, threat-driven penetration tests and the information register with ICT contracts. These delegated regulations came about in several rounds and the time between the final texts and the formal applicability of DORA was tight. In addition, the European Commission still needed time to adopt these proposals, and some proposals were also not adopted unchanged.
In concrete terms, this played out on two sensitive points. The ITS for the information register was rejected on September 3, 2024 because it included the LEI as a mandatory identifier for IT suppliers, while there are also free alternatives. The RTS on subcontracting was also not fully adopted. The Commission found that the ESAs had gone too far there by setting requirements for the entire chain of subcontractors, while the effect should have been limited to conditions for outsourcing. It is precisely these kinds of adjustments that make it clear why many institutions were unable to complete their implementation as if all the rules had been fixed for a long time. The delegated acts under DORA are now final, including the entry into force of the RTS on TLPT on July 8, 2025 and the publication of the RTS on subcontracting on July 2, 2025, with entry into force on July 22, 2025.
This is relevant for startups and scale-ups because DORA is not only about the main regulation, but also about the detailed rules that accompany it. Especially for fintechs and tech companies that deliver to financial institutions, it is therefore not enough to just know the basic framework. The real compliance pressure often lies in the implementation.
Harmonization does not mean that all the old guidance is suddenly gone
DORA must harmonize fragmented European and national rules. This quickly gives the impression that older guidelines will automatically disappear as soon as DORA applies. It's not that simple.
EIOPA has indeed withdrawn part of its previous guidance, including guidance on cloud outsourcing and ICT security and governance. EIOPA has also updated an existing opinion on operational risk management. EBA partly chose a different route: the ICT and security risk management guidelines have been updated to better suit DORA, while the 2019 outsourcing guidelines have remained in place for the time being. There were no updates on the status of ESMA guidelines, including guidance on cloud outsourcing, at that time. As a result, existing framework continued to exist there alongside DORA.
This tension is also reflected nationally. From January 17, 2025, DNB announced that it will only enforce on the basis of DORA and delegated regulations, and not also on the basis of Good Practice Information Security. This made a conscious decision to comply with the uniform European framework and to prevent deviations between national and European standards.
For young tech companies, this is an important practical point. Harmonization sounds like simplification, but in the transition phase, it can actually mean that multiple layers of guidance are relevant at the same time. Those active in or around the financial sector are therefore well advised not to assume too quickly that older supervisory documents no longer play a role anywhere. Rather, the question is: which documents have been withdrawn, which have been amended and which are still running alongside DORA for the time being? This nuance is legally and operationally important.
The scope of “ICT services” is broader, but also less absolute than expected
One of the most practical questions under DORA is what exactly qualifies as an ICT service. That is not a detailed discussion. The answer also determines which contracts come into view, which suppliers should be included in governance and documentation, and where the implementation burden will be placed.
On 21 January 2025, the European Commission clarified that the concept of ICT services under DORA is deliberately broad. When assessing, financial institutions should take into account the idea that DORA refers to a broad group of IT suppliers, even when financial institutions provide ICT services among themselves. At the same time, the Commission made an important exception. If a service is primarily a regulated financial service, and ICT is only a component or is inextricably linked to it, then that service should in principle be seen as a financial service and not as an ICT service under DORA. On the other hand, if it concerns an independent, separate service that meets the DORA definition, it does fall under the term ICT service.
It is precisely this nuance that is important for the market, because DORA's text itself left room for a broader reading for many parties. Moreover, the clarification came only after DORA had already become applicable. As a result, financial institutions may have first worked with a broader starting point in their implementation than ultimately proved necessary.
For startups and scale-ups, this directly affects the definition of your product or service. If you provide technology to a financial institution, the question is not only what you do technically, but especially how that service should be legally qualified within the overall service. That distinction can make a big difference in contract negotiations, customer requests for information and how you are included in their Dora approach.
The real bottleneck is not just in the rules, but in the implementation
The fact that DORA formally began to apply on January 17, 2025 did not mean that the sector was ready everywhere by that date. A sector-wide survey by DNB in the insurance and pension sectors showed that many institutions expected to need until at least the end of 2025 to fully comply with all requirements. At the same time, a large part of the respondents indicated that they have already made a long way, with 65 percent estimating that they have implemented around 70 percent of the DORA framework.
Where the gap seemed mainly to lie was in non-critical ICT services. Institutions, partly under the influence of regulators, have given priority to services that support critical or important functions. That makes sense. When time, capacity and clarity are limited, attention automatically shifts to the components with the greatest impact on operational resilience and supervision.
The implementation pressure is also easy to explain in terms of content. DORA includes a comprehensive set of requirements that must be implemented in addition to day-to-day operations. This requires governance, inventory, contract work, internal coordination and often also technical adjustments. For institutions that did not previously work with similar requirements, that step is extra big. In addition, some of the further regulations and guidance were only available late. Those who wanted to be compliant on time therefore had to build partly while the latest instructions were not yet final.
For founders and management teams, this is perhaps the most important lesson: DORA is not a check list that you put next to another compliance project. It is a change process that requires prioritization. So the order in which you address risks, suppliers, contracts and controls really matters. This practical reality also shows how the sector itself has had to phase out.
What this means for fintechs and other tech companies
For financial institutions and regulated fintechs
For parties that are themselves under financial supervision, the development around DORA mainly shows that compliance is more than just a legal memo. The organization must be able to work with a framework that was still filled out in detail while the main obligations were already in place. This requires an approach in which legal interpretation, operational execution and supplier management work together.
In addition, it appears that not everything can be worked out at the same level at the same time. Practice shows that prioritization takes place around critical and important functions. This is not a license to ignore other components, but it is a realistic lesson for teams with limited capacity. Anyone who wants to do everything equally deeply at the same time runs the risk of losing pace on the parts that are most urgent.
For SaaS companies and other IT vendors
For IT suppliers, DORA often works indirectly through customers. Financial institutions must register their ICT contracts, provide insight into their dependencies and be able to clearly explain which services they purchase and under what conditions. This increases the chance that suppliers will receive more questions about contract structure, services and subcontracting.
The discussion about subcontracting is particularly relevant here. After the adjustment of the RTS, contractual agreements no longer had to be about the entire chain of subcontractors, but only about the first rank of subcontractors. This is still a relevant data point for suppliers, but a less far-reaching outcome than was initially seen. For growing tech companies that work with multiple suppliers, such a nuance can make a big difference in contractual and operational burdens.
The definition of the term ICT service is also not an abstract exercise for suppliers. Whether your service is treated as an ICT service within DORA influences how customers include you in their register, what contract requirements they set and how intensively your service is assessed in their resilience framework. For tech companies that position themselves towards financial institutions, it is therefore wise to be able to clarify their own services in a legally clear way.
DORA continues to move, even after the effective date
An important follow-up process under DORA is the information register. Financial institutions had to submit their registers to their national supervisor in April 2025, after which that data went to European supervisors after validation. The purpose of this is not just administration. The registers should provide insight into which ICT services the European financial sector mainly uses, so that critical suppliers can be identified.
A lot is at stake for those critical suppliers. As soon as they are identified as critical, they fall under DORA's oversight framework. This means independent obligations under DORA and direct reporting to a supervisor. For the market as a whole, this shows that DORA is not only asking how financial institutions control their suppliers, but also how dependencies at the sector level are made visible and visible.
It doesn't stop there. Now that the RTS on TLPT has come into effect, regulators can also appoint financial institutions that must carry out mandatory threat-based penetration tests. In addition, test managers from the supervisor are linked to the relevant institution to supervise preparation and implementation. DORA is thus moving further from setting standards to recurring implementation, reporting and testing.
For startups and scale-ups in the financial sector's tech chain, this is the core: DORA is not a one-off implementation deadline, but a framework that is increasingly operationalizing. New reports, further instructions and supervisory actions ensure that the impact continues even after the first implementation phase is over.
Conclusion: DORA requires continued direction
Since January 17, 2025, DORA has not brought the financial sector into a calm and fully crystallized regime, but into a phase of continuous elaboration, clarification and implementation. This is reflected in the late completion of delegated regulations, in the various choices made by supervisors regarding existing guidance, in the clarification of the concept of ICT services and in the time that institutions need to make the whole thing workable.
For fintechs and other tech companies that do business with the financial sector, the challenge therefore lies not only in knowing the rules, but especially in being able to translate them into contracts, supplier relationships, priorities and internal execution. This is where it becomes clear whether DORA remains a paper obligation or grows into a mature part of digital resilience.



















