January this year seems a long time ago, but the Financial Services industry is now in a position to reflect on the implementation of the Digital Operational Resilience Act (DORA) and what is abundantly clear is that complying with this legislation is not a “one and done” exercise.

DORA compliance has become a top strategic priority with institutions now ranking it significantly higher than they did before the deadline. Senior executives need little reminder of the dangers of failing to build a robust strategy to defend their IT infrastructures, but if they do, the string of recent high profile cyberattacks on the likes of Marks & Spencer, the Co-Op and Jaguar Land Rover should be motivation enough to act on DORA. Add to this research from the Chartered Institute of Information Security (CIISec) and even those whose job it is to protect IT systems categorically state that the board must take responsibility for breaches. Therefore, the pressure is on for senior executives to get to grips with DORA.

Despite this elevated focus, the majority of organisations still believe they need significant improvements to meet DORA’s requirements fully – you only have to look at Skillcast’s report on DORA readiness to see that some financial services sectors, like banking and lending, are significantly behind schedule.

Part of the challenge is that it is still not 100% clear what compliance really means, and how institutions should corral the appropriate support within their organisations and with their suppliers. Although the regulation has begun to be embedded into broader resilience programmes, many struggle with the concrete reality of the mandate’s implementation months after the enforcement deadline. The primary barriers to compliance include the already overwhelming pressure on stretched IT and security teams, substantial budget constraints, and the lack of clarity about what counts as compliance.

Navigating the Compliance Maze: Key Questions Surrounding DORA

It should be no surprise that we are commonly hearing questions like: “When are we actually done?”, “Are we now compliant?” and “Where are we actually in the compliance process?”

All this confusion could be summed up by the remark echoing around many financial institutions: “How do we know when we’re compliant?”

Looking at an FAQ that the law firm, Osborne Clark, has written on DORA it is easy to see why there are so many open questions about the legislation. Things like:

  • If a financial entity delivers a service to another financial services company, should it be treated as an ICT provider, and therefore fall under the requirements of DORA for third-party services?
  • Under DORA, the financial services institution or regulated entity has responsibility for compliance with DORA, so how do you ensure outsourced ICT providers are compliant?
  • Proportionality is another headache, as the regulated entity is required to take into account the size and overall risk profile of an ICT provider, as well as the scale and complexity of the services being used when deciding how strictly the third party should comply with the obligations of DORA.
  • There is also cross-over with other regulations such as the EU AI Act, GDPR, NIS2 and ISO 27001. How do you decide whether compliance with DORA supersedes or is sufficient to ensure compliance with other regulations?

Organisations are hindered by the sheer volume of digital regulations which could even become a barrier to innovation, and competing internal voices argue the regulation is little more than practices their institutions have already been following to comply with SOC 2, ISO 27001:2013, TISAX, etc. There is further uncertainty around enforcement, how compliance will be measured, and what the consequences of non-compliance are for financial services companies.

Complex Java Environments Underscore the Difficulty of Third-Party Risk Management

Third-party risk oversight is emerging as one of the most challenging aspects of DORA. It is the most difficult requirement to implement because it is so complicated to get the requisite insight into extensive vendor ecosystems, while also creating comprehensive inventories of ICT assets across decentralised operations. Assessing subcontractors and maintaining firm-wide visibility of functions poses major operational challenges, particularly for larger institutions with complex supplier networks, and the likely level of regulatory oversight will limit the time and resources available to implement these requirements.

As one of the stewards of the Java programming language, in our world of providing OpenJDK software solutions to financial services organisations, this is particularly important. We focus on Java applications and infrastructure which are widely used in this industry as they have the performance, scalability and robustness needed to manage high volume transactions. The difficulty, though, is that Java has been around for 30 years and has gone through many iterations. As a result, there are different versions of the Java Development Kit (JDK) floating around and actively being used in Azul’s financial services industry customer’s IT systems. For example, in our 2025 State of Java Survey & Report we found 10% of users were still on JDK 6 and 13% were on JDK 7 – both versions now no longer supported by anyone other than Azul. A further 31% are on JDK 21 which will lose free support from Oracle in September next year.

With Java playing such an important role in enabling financial services industry customers to better manage operation of their IT systems, monitoring all these different versions to ensure they do not lead to vulnerabilities is challenging. Organisations are ultimately responsible for control and monitoring of their internal systems but then they must evaluate how a third party provider can assist them in meeting their DORA compliance requirements. Having seen the impact of the Log4j vulnerability and knowing almost half the companies (49%) in the 2025 State of Java survey revealed that they had experienced security vulnerabilities from Log4j in production three years later, it emphasises that compliance with DORA requires constant monitoring and evaluation of potential threats.

Staying Ahead of DORA: Strategic Compliance in a Shifting Landscape

In the future, the need for financial services organisations to remain on their guard will intensify as new and changed oversight requirements are tacked onto DORA, or via its supplements and additional guidelines. 2025 is a transition year as many manual reporting obligations will become automated over time, but this will require additional system investments. The potential expansion of DORA’s scope to include statutory auditors and other currently excluded entities could further complicate managing compliance at a time when cybersecurity skill shortages are already creating challenges.

The bottom-line is that evolving cyber threats will further require ongoing and increasingly complex adaptations to the framework. Senior leadership teams will never really be able to say they have fully completed the implementation of their DORA strategies. Instead, organisations must adopt strategic, risk-based approaches starting with comprehensive gap assessments and phased implementation roadmaps. Investment in automation and technology over time will also significantly reduce manual compliance burdens and improve the accuracy of monitoring and reporting. In addition, participation in industry consortiums will enable access to shared resources and expertise, which will reduce individual compliance costs. Most importantly, financial organisations must reframe DORA compliance as an opportunity to modernise their infrastructure, at least in a phased approach and incrementally as they make decisions about future IT strategies. They should see it as an opportunity to strengthen their competitive positioning rather than solely view it as a regulatory burden. After all, DORA is implemented in the best interest of institutions and consumers, and organisations should embrace that intention.