Your legacy system just failed its DORA audit. Now what?

• DORA and NIS2 expose architectural gaps that policies alone cannot fix
• Batch-based legacy systems struggle with real-time detection and reporting requirements
• Undocumented dependencies undermine ICT asset inventory obligations
• Mainframe concentration risk is now a supervisory concern
• A documented modernisation program is the strongest regulatory position

DORA (Digital Operational Resilience Act) requires capabilities that legacy architectures were never designed to deliver.

DORA is no longer a future compliance exercise. It is in force, actively enforced, and focused on operational resilience, observability, and control. Many legacy environments can meet documentation requirements, but struggle to meet architectural ones.

Batch-oriented processing, undocumented dependencies, and single-vendor platforms create gaps that cannot be closed through process improvements alone.

DORA is not just a compliance challenge. It is a modernisation trigger.

In most legacy environments, critical dependencies are embedded in code, not documentation.

DORA requires a continuously accurate, auditable inventory of ICT assets and their interdependencies. In many mainframe estates, these relationships exist only in batch chains, job schedulers, and informal knowledge held by long-tenured engineers.

Automated dependency mapping is increasingly the only credible way to meet this requirement and it simultaneously becomes the foundation for any realistic modernisation roadmap.

Legacy architectures detect incidents too late, often only after batch cycles complete.

DORA mandates detection and reporting of major ICT incidents within hours. Batch-based systems delay visibility until scheduled processing finishes, making timely response difficult or impossible.

Modern observability, real-time monitoring, tracing, and alerting cannot be meaningfully retrofitted onto architectures that were never designed for it. This is not a governance gap. It is a design limitation.

It also explains why many AI initiatives fail in legacy environments without real-time data and observability systems, reinforcing the need for AI Modernisation.

It turns long-accepted dependencies into explicit concentration risks.

DORA requires institutions to identify and manage ICT third-party concentration risk. Core systems dependent on:

• Single hardware vendor
• Middleware stack
• Shrinking talent pool now falls directly within supervisory scope.

While DORA does not mandate immediate exit from mainframes, it does require institutions to demonstrate active risk management and reduction over time.

Modernisation efforts, therefore, shift from a cost initiative to a regulatory necessity.

Supervisors are not looking for perfection. They are looking for control and execution.

The strongest position is a documented, board-approved modernisation program that explicitly maps architectural remediation to regulatory requirements. Institutions that can demonstrate structured progress are far better positioned than those relying on intent or future plans.

In practice, this means moving beyond isolated fixes toward end-to-end modernisation from dependency mapping and architecture redesign to real-time observability and AI-ready data foundations. These capabilities are also essential for successful AI Modernisation initiatives, enabling organisations to scale AI on resilient, observable, and compliant technology foundations.

Similar regulatory frameworks are emerging worldwide. Frameworks such as the UK's Operational Resilience regulations, Australia's CPS 230, Singapore's MAS Technology Risk Management Guidelines, and NIS2 all reinforce the need for greater resilience, technology risk visibility, and effective management of critical systems and dependencies. While the regulatory details differ, the direction is clear: organisations must strengthen the architectural foundations that support critical business operations.