DORA does not explicitly say ‘replace your old systems’. However, its requirements – annual testing of systems supporting critical functions, source code reviews, scenario-based testing (at least once every three years for designated TLPT entities), and documented RTOs and RPOs – are, in practice, impossible to meet for undocumented applications written in Delphi, VB6 or legacy Java EE. The problem is not that such a system ‘doesn’t work’. The problem is that it is impossible to reliably prove that it is resilient. Below, we show exactly where the old stack fails DORA’s requirements and what can be done about it without a complete overhaul.
What exactly does DORA require in terms of testing?
DORA (EU Regulation 2022/2554) has been fully in force since 17 January 2025. Its fourth pillar – digital resilience testing (Articles 24–27) – treats testing not as an occasional audit, but as an ongoing programme that forms part of ICT risk management. In practice, this means three things that are important for legacy systems.
Firstly, all systems and applications supporting critical or essential functions must be tested at least once a year. The list of methods is not exhaustive, but includes, amongst other things, vulnerability assessments, source code reviews, network security tests and scenario-based testing.
Secondly, designated entities must carry out advanced threat-led penetration testing (TLPT) at least once every three years. The detailed technical standards for TLPT (EU Delegated Regulation 2025/1190) come into force on 8 July 2025 and are consistent with the TIBER-EU framework. The national supervisory authority determines which entities are subject to TLPT on the basis of the criteria set out in Article 26(8) – including systemic importance, ICT risk profile and technological maturity.
Thirdly, the scale of the phenomenon is not merely theoretical. The first annual review of serious ICT incidents under DORA (published by the European supervisory authorities in June 2026, covering the year 2025) recorded 3,383 serious incidents in the EU’s financial sector, of which around one-third had cross-border implications. Resilience is no longer just a topic for a slide presentation; it has become a requirement that must be demonstrated.
Why does the old stack lose out here?
Legacy systems do not fail DORA simply because they are old. They fail because it is impossible to reliably carry out what DORA requires on them. This is evident in four areas.
Lack of testability. Monolithic applications in Delphi or VB6 are rarely covered by automated tests or environments in which failure scenarios can be safely reproduced. Without this, annual scenario and regression tests either become a costly, manual undertaking or are not carried out at all.
Reviewing source code without people who understand it. DORA explicitly lists code review as one of the methods. With legacy Java EE or VB6, the problem is often not just a lack of testers, but also a lack of people who understand the logic at all – and sometimes source code that is incomplete or out of sync with the production environment.
A lack of documentation, i.e. no BIA, RTO or RPO. DORA requires the identification of critical functions and a specification of how quickly the system can be restored and with what level of acceptable data loss. If no one knows which processes depend on a given system and how it behaves in the event of a failure, the business impact analysis (BIA) is based on guesswork.
Dependencies as black boxes. The legacy stack often contains key logic and integrations that nobody has mapped out. Without this map, it is impossible to sensibly define the scope of testing or assess the ‘impact radius’ of a single failure – and this is the crux of resilience assessment.
There is one common factor: it is not that the system is bad, but that it lacks transparency. And DORA penalises a lack of transparency.
This is not an argument in favour of the ‘Great Replacement’
It is easy to draw the conclusion that ‘if the old system fails the tests, it must be replaced’. This is usually the most expensive and riskiest solution – and, moreover, an unnecessary one. DORA does not mandate the replacement of systems. It requires proven resilience and effective management of ICT risks. These are two different things.
The sensible approach is the opposite of the instinctive one. First, visibility: taking stock of processes and reconstructing documentation. Then, testability: bringing the system to a state where it can be reliably tested and monitored. Only at the very end, where it is actually justified, should targeted modernisation take place. Very often, it turns out that to achieve DORA compliance, all that is needed is to recapture the necessary knowledge and build a test programme around the existing system, without rewriting it from scratch.
Where should I start?
Preparing an old stack for DORA is a project that starts with information, not code.
Process Inventory and Dependency Map. A thorough process inventory using the Event Storming method helps identify critical functions, interdependencies between systems, and real risk points. This forms the foundation of a BIA and a sensible test scope.
Automatic, up-to-date architectural documentation. The S*.doc tool recreates multi-layered, always up-to-date system documentation within your own infrastructure. This is a prerequisite for code reviews, defining the scope of TLPT and demonstrating ICT governan
An IT architecture audit combined with DORA consulting allows you to map gaps relative to Articles 24–27, determine RTO and RPO, and design a testing program proportional to the risk profile.
The result is not just ‘paper for the filing cabinet’, but a starting point at which the old system ceases to be a black box – and becomes testable, monitorable and capable of being defended against surveillance.
FAQ
Does DORA require the replacement of legacy systems?
Which legacy systems are subject to DORA testing?
What is TLPT and who does it apply to?
Why is the lack of documentation for legacy systems a problem under DORA?
Where should I start when preparing for DORA with the old stack?
Does your organisation have systems built in Delphi, VB6 or legacy Java EE, and are you unsure whether they’ll pass the DORA resilience tests? Let’s have a chat – we’ll start by mapping the gaps, without assuming from the outset that everything needs to be rewritten.
