DORA without the busywork: building ICT risk management into the system itself

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. To comply with it, a financial entity needs, among other things, to build and run an ICT risk management framework. Chapter II of the regulation (Articles 5 to 16) sets out that framework, and the detail sits in Delegated Regulation (EU) 2024/1774, the regulatory technical standard (RTS). Nor is it a one-off: under Article 6(5), the framework has to be reviewed at least once a year, and after every major ICT-related incident too.

That sounds like endless paperwork: registers, assessments and reports, all ahead of the next review. But the RTS is surprisingly concrete. It spells out what an asset record holds, which events are logged, what a change procedure contains and what the review report covers. Nearly all of that is data a running system produces anyway. The system just has to be built to keep it. Then most of the routine can be automated rather than compiled by hand every year. The hardest cases are systems that were never built for this, so let's start there.

Legacy: an assessment before and after every connection

Article 8(7) of DORA has every financial entity other than a microenterprise run a specific ICT risk assessment on all legacy ICT systems. That happens at least yearly, and also before and after connecting technologies, applications or systems. Article 3(3) defines a legacy ICT system as one that is still in use and meets one of these conditions:

• it has reached end of life;
• it cannot be upgraded or fixed;
• it is no longer supported.

Say your core banking system fits that definition. Then every new channel means two assessments, one before you connect it and one after. That channel could be a mobile app, a partner API or a new payment service.

So where do you record what actually changed? The easiest place is the adapter and orchestration layer around the core. In this architecture, a new channel doesn't connect to the core directly; it connects to that layer. The legacy core usually can't tell you much about itself: its logs are thin, its interfaces are old, and changing it is expensive and risky. The layer around the core is different. It's modern code you control. It's versioned, it goes through the pipeline, and it knows which channel calls which core functions.

Connecting a channel therefore turns into concrete, visible changes in that layer: a new route, a new or updated adapter version, or changed configuration. For the "before" assessment, you have the current picture: which core functions are exposed, who calls them, at what load and with what error rate. For the "after" assessment, you have the same picture with the new channel in it. The difference between the two shows up in the change history. The same layer is also a handy source of interdependencies for the asset inventory, which we'll come to below.

What the RTS wants a system to keep

Translate the requirements of Chapter II and the RTS into engineering terms and you get a very concrete list. For each duty, the table shows where it sits and what the system has to do.

A couple of practical tips. Article 8(6) has inventories updated every time a major change occurs. Done by hand, that quickly turns into a chore. If asset records are generated from deployment descriptors and infrastructure state, they update themselves.

Changes are even simpler. Set up the pipeline so that it only promotes a build approved by someone other than its author. That is the separation RTS Article 17 asks for, and the pipeline's history becomes a ready-made change record.

Incident classification runs on the same data

When something breaks, Article 18 of DORA has the incident classified on six criteria, and Delegated Regulation (EU) 2024/1772 sets their thresholds. An incident is major when it affects critical services and one of two conditions holds:

• it involves successful, malicious and unauthorised access that may lead to data losses;
• it crosses at least two of the other thresholds.

The good news is that most of those thresholds are numbers:

• how many clients and transactions are affected;
• how long the incident lasts and how long the downtime was;
• how many Member States it reaches;
• how large the costs and losses are.

The bad news is that you need those numbers right away, while the incident is still open. Along with them, you need when the anomaly began and when it was detected. And the clock is ticking. Under Delegated Regulation (EU) 2025/301, the initial notification is due within four hours of classification. It must also go out no later than 24 hours after the entity became aware of the incident. Our DORA explainer walks through the full sequence and includes a checklist for an engineering team.

There's a separate trap in Article 8(2) of the same Delegated Regulation 2024/1772. It's a good test of how carefully you record incidents. Several incidents that are not major one by one count as one major incident when three conditions hold:

• they occurred at least twice within six months;
• they share the same apparent root cause;
• together they meet the major criteria.

This has to be checked monthly, although microenterprises and entities under the simplified framework are exempt. The check needs a root-cause field with a fixed vocabulary, linked to the asset record. Free text along the lines of "something with the database" won't cut it.

The orchestrator and wrappers: incident data and safe rehearsals

In our article on core transformation seams, we described a real project. In it, card personalisation runs in production behind a single orchestration service. Each legacy system sits behind its own wrapper service, which hides that system's protocol. For DORA, this setup turns out to be very convenient, for two reasons.

First, every substantive step of those flows runs through the orchestrator. That means the orchestrator can attach a correlation identifier to each request and log each call to each wrapper. It can also count failed requests per legacy system and per client. That's exactly the raw material for the numbers the classification thresholds use.

Second, wrappers make failure cheap to rehearse. Point a wrapper at a stub and watch how the orchestrator behaves, without touching the legacy system itself. Rehearsals like this can feed the yearly plan tests under Article 11(6). Just bear in mind that RTS Article 25 still expects the switchover to redundant capacity itself to be tested, and a stub doesn't replace that.

The pattern is written up in more detail in our practitioner guide to the orchestration layer.

Write the register last

The final document of the whole cycle is the yearly review report. RTS Article 27 sets out its content: findings on weaknesses, deficiencies and gaps, remediation measures with deadlines, and the status of earlier measures. The competent authority can request the report. Work back from it and the order falls into place:

1. First come the records in the system itself: assets from infrastructure state, changes from the pipeline, and logging and alert thresholds as versioned configuration.
2. Next come the register and the incident classification, fed from those records.
3. The review report comes at the very end, written from the register, the test results and the year's incidents.

In that order, the register describes the system that is actually running, not the one someone once drew on a diagram. And much of the review report draws on records you already have.

Core and channel work we've already shipped

Legacy core to modern digital banking: 1.5M+ users migratedProgressive banking super app: 1.5M+ installations