Since 17 January 2025, how a bank keeps its core systems monitored, patched, recoverable and replaceable has been a compliance question as well as an engineering one. DORA, the EU's Digital Operational Resilience Act, writes each of those into law, and it names legacy systems directly: every one needs its own risk assessment at least once a year. DORA compliance for an old system therefore starts in the code and the runtime, before the policies.
What DORA compliance requires from financial entities
The DORA regulation, formally the Digital Operational Resilience Act (Regulation (EU) 2022/2554), applies to twenty types of financial entity, from credit institutions, payment and e-money institutions to investment firms, crypto-asset service providers, insurers and pension funds (Article 2). It reaches their technology suppliers through contracts, and the largest of those suppliers directly, through EU oversight of critical ICT third-party providers. The rules scale with size and risk (Article 4), and small, less interconnected firms follow a simplified framework (Article 16).
The obligations fall into four areas that matter for engineering, plus voluntary information sharing on cyber threats (Article 45):
| Area | Articles | What it requires | Evidence a supervisor can ask for |
|---|---|---|---|
| ICT risk management | 5 to 16 | A framework owned by the management body; inventories of assets and dependencies; protection, detection, backup and recovery | Asset inventory, risk assessments, logging and patch policies, recovery test results |
| Incident management and reporting | 17 to 23 | Detecting, classifying and recording ICT incidents, and reporting major ones to the supervisor on fixed deadlines | Incident register, classification records, the reports themselves |
| Digital operational resilience testing | 24 to 27 | A testing program from vulnerability scans to end-to-end and performance tests; threat-led penetration testing (TLPT) for the largest entities | Test plans, results and remediation tracking |
| ICT third-party risk | 28 to 44 | A register of every ICT contract, mandatory contract terms, exit strategies for critical services, and oversight of critical providers | Register of information, contracts, exit plans |
ICT risk management: inventories, detection and recovery
Article 8 asks for every ICT-supported business function, information asset and ICT asset to be identified, classified and mapped with its dependencies, and the inventories kept current. The technical standard that details the framework, Commission Delegated Regulation (EU) 2024/1774, lists what each asset record holds (Article 4). Among the fields: the asset's owner, the business functions it supports, whether it is exposed to the internet, its recovery time and recovery point objectives, and the end dates of the ICT third-party service provider's regular, extended, and custom support services
.
Detection is spelled out too. Article 10 of DORA requires mechanisms to promptly detect anomalous activities
, with alert thresholds and automatic alerts to the incident response staff. The standard's logging article (Article 12) adds the specifics: which events are logged and for how long, protection of logs against tampering and deletion, a way to detect when logging itself fails, and clocks synchronized to a reliable time source.
Recovery has to be demonstrated. Article 11 requires a tested ICT business continuity policy, and Article 12 requires backup and restoration procedures whose testing shall be undertaken periodically
.
Incident reporting deadlines
Article 17 requires a process to detect, classify and record every ICT-related incident, and Article 19 requires major incidents to be reported to the competent authority, which for significant banks passes them to the ECB. The technical standards on incident reports (Delegated Regulation 2025/301 and Implementing Regulation 2025/302) set three deadlines, as the European Supervisory Authorities summarize them: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report no later than one month after the intermediate report.
The first full year produced real numbers. In 2025, financial entities reported 3,383 major ICT-related incidents (ESAs report on major ICT-related incidents, June 2026). Half were caused by a system failure or malfunction, and 29% by a failure attributable to a third-party provider.
The classification depends on numbers: how many clients were affected, for how long, which services and countries, how much data. A system that cannot answer those questions from its own telemetry within hours cannot meet the first deadline with any confidence.
Resilience testing and TLPT
Article 25 lists the tests a testing program should draw on: vulnerability scans, source code reviews where feasible, scenario-based, compatibility, performance, end-to-end and penetration tests. Entities that supervisors identify for advanced testing carry out threat-led penetration testing at least every three years, on live production systems
supporting critical or important functions (Article 26).
ICT third-party risk: the register and exit plans
Every contract for ICT services goes into a register of information, distinguishing services that support critical or important functions from the rest (Article 28(3)). Supervisors collect the registers every year; the first collection ran in spring 2025. In the ESAs’ dry run of 2024, only 6.5% of the 947 registers analyzed passed all data quality checks. A register is only as good as the asset inventory behind it, and legacy systems are where that inventory is thinnest.
For critical or important services, Article 28(8) requires exit strategies: the entity must be able to leave a provider without disruption to their business activities
, without limiting compliance and without detriment to clients, with exit plans that are documented and tested. Article 30 makes the contract itself carry part of this, including a mandatory transition period during which the provider keeps the service running while the entity migrates. On 18 November 2025 the ESAs designated the first 19 critical ICT third-party providers, among them AWS, Google Cloud, Microsoft, Oracle, SAP, IBM, Kyndryl, FIS, Accenture and Tata Consultancy Services, which are now overseen directly at EU level.
What DORA means by a legacy ICT system
DORA defines the term. A legacy ICT system is one that has reached the end of its lifecycle (end-of-life), that is not suitable for upgrades or fixes, for technological or commercial reasons, or is no longer supported by its supplier or by an ICT third-party service provider, but that is still in use
(Article 3(3)).
Article 8(7) then sets the obligation: financial entities other than microenterprises shall on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems and, in any case before and after connecting technologies, applications or systems
.
The last clause matters for modernization. Every new API, payment integration or cloud service connected to an old core triggers an assessment before and after the connection.
Supervisors are pushing in the same direction. In a letter of 7 July 2026 to the CEOs of the banks it supervises directly, the ECB asked for action plans by 31 October 2026 and listed among the structural measures modernising infrastructure by replacing or updating legacy, unsupported or end-of-life technologies
. Two years earlier, its cyber resilience stress test of 109 banks concluded that banks should also be able to meet their own recovery objectives
.
For Java systems, the definition turns on support contracts as much as on age. Oracle ended premier support for Java 8 in March 2022, and extended support, which is paid, runs to December 2030. Spring's open-source support for Spring Boot 2.7 ended on 30 June 2023 and for Spring Framework 5.3 on 31 August 2024, with paid commercial support to 2029. A Java 8 system with Spring Boot 2.7 and a paid extended-support contract for both may fall outside the definition; the same system on free builds that no longer receive fixes falls inside it. The inventory field for support end dates exists to make that distinction visible. Our Java end of life dates guide has the full calendar.
Where legacy systems fail DORA checks
Most of the gaps we find on old financial systems fall into four groups:
| DORA requirement | Typical gap on a legacy system | What closes it |
|---|---|---|
| Detect anomalies and classify incidents within hours (Articles 10, 17, 18) | Logs in local files with no correlation IDs, no metrics, alerts on server health only | Structured logs, metrics and traces on the critical business flows, with alerts tied to the classification criteria |
| Patch policy and support end dates (Article 9(4); RTS Article 4) | A JDK, framework or application server out of support; libraries with known vulnerabilities and no fixed version | Upgrade to a supported runtime and framework, or isolate the system and document compensating controls |
| Tested backup, restore and continuity (Articles 11, 12) | Restores done by hand from a runbook nobody has followed since the last data center move | Scripted restore and failover, run on a schedule and timed against the recovery time objective |
| Exit strategy for critical providers (Articles 28(8), 30) | A vendor-built core with no source access, a provider that no longer exists, or knowledge held by one person | Documented interfaces and data exports, contract terms with a transition period, and a tested path to an alternative |
No observability on the critical path
Many older Java systems were built when a log file and a server health check were enough. They can say that a process is running; they cannot say how many payments failed in the last fifteen minutes or which clients were affected. DORA's incident classification asks exactly those questions, on a deadline.
Adding observability to an old system rarely needs a rewrite. The OpenTelemetry Java agent is added to the JVM at startup, with no code changes (the OpenTelemetry documentation says it works with any Java 8+ application
) and records inbound requests, outbound calls and database queries. A handful of business metrics (transactions processed, failed, delayed) on the critical flows covers most of what classification needs. Logs then need the controls the RTS lists: retention, tamper protection and an alert when logging stops.
Unsupported runtimes and libraries
Article 9(4)(f) requires documented policies for patches and updates. A policy is easy to write; applying it to a system whose runtime no longer receives fixes is not possible. The same holds for libraries: a dependency scan of an old Java core usually finds components whose only fix is in a newer major version, or that have no fix at all. Our guide to SBOMs for Java applications shows how to produce that inventory from the build and check it for vulnerable and end-of-life components.
When an upgrade cannot happen this year, the alternative is containment: no direct internet exposure, network segmentation so the system can be cut off quickly (Article 9(4) asks for exactly that capability), stricter access control and more monitoring. The ECB’s July 2026 letter names the same two options: replacing or updating such systems, or providing comprehensive protection through additional controls where replacement is not feasible
(ECB). Containment has to be written into the yearly legacy assessment, with a date by which the system is upgraded or replaced.
Recovery that has never been tested
Batch-based cores often depend on restore procedures that were written once and never run in full. DORA expects the recovery time objective in the asset inventory to be backed by a test that met it. In our experience, the first full restore test on an old system finds something missing: a configuration file outside the backup, a manual step, a dependency on a server that was retired.
No exit plan
The exit requirement is hardest for systems built or run by a single vendor. If the source code, the deployment knowledge or the data formats sit with a provider, an exit plan has to start with getting them out: documented interfaces, regular data exports in an open format, and contract terms that keep the provider supporting the system through a transition.
The best-documented failure of this kind predates DORA. In April 2018 TSB moved its customers to a new platform run by an outsourced provider; according to the Bank of England, all of its branches and a significant proportion of its 5.2 million customers were affected, and the bank did not return to business as usual until December 2018. The FCA and PRA fined it £48.65 million in December 2022. The FCA final notice found failings in planning, testing, risk management, and outsourcing
, and that TSB did not sufficiently understand SABIS’s capability to operate the platform
. The UK has its own operational resilience rules, but each of those failings has a DORA article written against it today.
Outages have not stopped since. The UK Treasury Committee collected data from nine large banks and building societies: at least 158 IT failure incidents and 803 hours of unplanned outages between January 2023 and February 2025, with problems at third-party suppliers, system changes and software malfunctions among the common causes. In one Barclays outage in early 2025, the bank said 56% of online payments failed because of severe degradation of its mainframe processing performance.
A DORA remediation roadmap for legacy systems
The order below follows the dependencies between the steps: nothing can be prioritized before it is inventoried, and recovery cannot be tested on a system that cannot be observed.
| Step | What to do | Evidence it produces |
|---|---|---|
| 1. Inventory | List every ICT asset behind critical or important functions with its owner, dependencies, internet exposure, RTO, RPO and support end dates; generate an SBOM for each application | Asset inventory and the input for the yearly legacy risk assessment (Article 8(7)) |
| 2. Observe | Add structured logs, business metrics and traces on the critical flows; tie alerts to the incident classification criteria; protect and monitor the logs | Detection and logging controls (Article 10; RTS Article 12) |
| 3. Patch or contain | Upgrade the JDK, framework and libraries to supported versions; where that waits, segment and restrict the system and record the compensating controls | Patch policy in practice, vulnerability scan results (Article 9) |
| 4. Recover | Script restore and failover; run them on a schedule; record the measured recovery times | Backup and continuity test results (Articles 11, 12, 25) |
| 5. Exit | Document interfaces and data exports; agree transition terms with each critical provider; test the exit path at least on paper, ideally on data | Exit plans and contract terms (Articles 28(8), 30) |
In our projects, steps 1 and 2 take weeks, and they decide the size of the rest. Step 3 is where most of the engineering cost sits, and where modernization and compliance become the same project.
Combining DORA work with ISO 20022 migration and core banking modernization
DORA is not the only deadline landing on old payment and core banking systems. The Eurosystem moved its T2 settlement system to the ISO 20022 message standard in March 2023 (ECB), the Fedwire Funds Service switched on 14 July 2025 (Federal Reserve), and Swift ended the coexistence of MT and ISO 20022 messages for cross-border payments on 22 November 2025 (Swift). A bank whose core still produces MT messages relies on translation somewhere in the chain, and an ISO 20022 migration touches the same payment code that DORA asks it to monitor, patch and recover.
The systems that need DORA remediation are usually the same ones that carry the payment formats and the core ledger, so the work is cheaper planned once. A strangler approach suits all three: new services take over one function at a time behind a stable interface, each new service is observable and supported from the start, and the old core shrinks while it keeps running. Our guide to the strangler pattern covers the mechanics, and data migration strategy covers moving the data underneath.
We have worked on financial systems since 2013, starting with FastPost, a ledger for Legerity that processes a billion transactions in under an hour. For banks and fintechs we modernize Java 8 cores a few modules at a time and build the DORA evidence (runbooks, tests, inventories) as part of the engineering work.
If you have a legacy system on your DORA risk list, book a scoping call. We will look at the inventory, the runtime and the recovery path with you and give you a written ballpark for the remediation.