DORA is a transparency mandate, not a migration mandate

The European financial industry has had DORA on its risk register since its adoption in 2022, and the regulation has applied since 17 January 2025. In practice, most of the DORA conversations I have with banks and insurers still start in the wrong place. People open with availability targets, backup strategies, and third-party risk management. Those matter, but they are not the hard part. The hard part of DORA is transparency, and this is where most mainframe estates fail the test.

What DORA actually says

DORA (Regulation (EU) 2022/2554) has five pillars: ICT risk management, incident reporting, operational resilience testing, third-party risk, and information sharing. The first pillar is where the pressure sits. Chapter II of the regulation requires financial entities to identify, classify, and document all ICT-supported business functions, information assets, and their interdependencies. Article 8 is explicit: institutions must maintain inventories of these assets and update them whenever the estate changes, and they must identify all sources of ICT risk on a continuous basis. Article 8 also requires a specific risk assessment of all legacy ICT systems at least once a year. Article 9 requires protection and prevention measures that follow a risk-based approach, in other words measures that are demonstrably aligned with identified risks.

In other words, the regulator is no longer asking whether your systems work. The regulator is asking whether you can prove you understand what your systems do. That is a different question, and for most mainframe environments it is a much harder one.

Why transparency is the number one priority

The other pillars of DORA are demanding, but solvable with engineering effort. Backup strategies can be improved. Incident reporting can be automated. Red team exercises can be scheduled. These are all well-defined problems with well-defined solutions.

Transparency is different. Transparency is not a process you add on top of a system. It is a property that either exists in the system or does not. Either you can explain, in auditable detail, how a premium calculation flows through your policy administration stack, or you cannot. Either you can map a specific COBOL paragraph to the business rule it implements, or you cannot. The hardest part of DORA compliance for most Tier 1 institutions is reconstructing understanding of the systems they already run.

Hence, transparency becomes the blocking dependency for the rest. You cannot do meaningful risk management on a black box. You cannot do meaningful resilience testing on a system whose behaviour you do not fully understand. You cannot credibly claim third-party risk controls over interfaces whose semantics have not been documented in a decade. Every other DORA pillar leans on the transparency pillar.

The gap on the mainframe

This is where the problem gets concrete. A typical Tier 1 European insurer runs over 30 million lines of COBOL and PL/I on the mainframe, some of it written in the 1970s. The original authors have retired. Documentation exists, but it has drifted from the code over decades of changes. Tribal knowledge lives in a shrinking pool of specialists, many of them within five years of retirement.

The result is a collection of three sources of truth:

• The code, what the system actually does (along with telemetry data)
• The documentation, what the business believes the system does
  
• Tribal knowledge, what people "just know"

In our engagements we consistently find that these three sources still leave blind spots. You find some information from the documentation, some from the code and the rest you just need to get from tribal knowledge. But sometimes, there are things that nobody knows. This gap is knowledge debt, and under DORA it is no longer just an operational nuisance, but it is a compliance liability.

What transparency actually requires

To meet the DORA transparency bar, an institution has to reconcile those three sources and produce a verifiable map from business process down to executing code. That is a structural problem, not a documentation problem. Writing more Confluence pages does not solve it, because the documentation will drift again within two release cycles.

The only approach that holds up is to derive the map from the artifacts themselves and keep it continuously synchronised. This is what we built Nomain to do.

Our deterministic analysis layer parses COBOL and PL/I into an abstract syntax tree and extracts the actual control and data flow. Not a probabilistic summary of it, but the real thing. We then align this against three inputs: the documentation you already have, the runtime telemetry from your SMF and CICS data, and your own business-process descriptions. The output is a live map that shows which code paths implement which business processes, where documentation diverges from reality, and where telemetry reveals behaviour that nobody currently owns.

Basically, when an auditor asks how a claim payout routes through the system, the answer stops being a tribal narrative and becomes a reproducible, version-controlled trace. You go from “ask Peter, he knows” to “here is the map, here is the code, here is the last transaction that took this path.”

Where this leaves you

If you are a CIO at a European bank or insurer, the question is not whether you need to address mainframe transparency. DORA has answered that for you. The question is whether you do it with a manual documentation effort that will drift within a year, or with an automated, deterministic pipeline that stays in sync with the code it describes.

We think the answer is obvious.