Five months of DORA at a financial entity: what actually mattered

This case history describes a DORA readiness programme carried out for a financial entity subject to Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It is written without details that would identify the client: what remains is the path, the technical choices and what proved useful.

The programme ran for five months and closed with 38 of the identified gaps resolved and a complete register of critical ICT providers. How it got there matters more than the numbers.

First question: DORA or NIS2?

Banks also appear in Annex I of the NIS2 Directive, so the question always comes up: which of the two applies? The answer is in Article 4 of NIS2. Where a sector-specific Union act imposes risk-management or incident-reporting obligations at least equivalent to those of the Directive, the corresponding NIS2 provisions do not apply to those entities. For financial entities, that act is DORA.

In practice this means a single reference framework for ICT risk and incidents, not two parallel programmes. It does not mean NIS2 disappears altogether: it continues to apply to entities the sector-specific act does not cover, and the scope has to be checked case by case, including against national transposition. In the programme described here, DORA was the operational reference from the start.

The starting point: solid IT, little evidence

The IT function was operationally solid. What was missing was the level of formalisation and documentary evidence DORA requires: doing things was not enough, the entity had to be able to demonstrate them in a structured way.

Three areas were the most critical: ICT risk governance; an incident classification and reporting process consistent with the regulatory thresholds; and above all the management of ICT third-party providers, with a register of arrangements and an assessment of critical providers to be built almost from scratch. The constraint was just as clear: do not overload a team already busy with day-to-day work, and do not produce documents detached from operational reality.

The gap analysis across the five pillars

The first step was a gap analysis against the Regulation’s five pillars: ICT risk management (Chapter II), ICT-related incident management, classification and reporting (Chapter III), digital operational resilience testing (Chapter IV), ICT third-party risk (Chapter V) and information sharing (Chapter VI).

For each requirement there were three possible answers: already in place, in place but needs formalising, needs building. It sounds trivial, but it decides the cost of the programme. What exists must be made demonstrable, not redone; what is missing is built once, without duplicating controls already in use.

ICT risk governance: roles, responsibilities, reporting

DORA gives the management body ultimate responsibility for managing ICT risk (Article 5). Without a regular flow of information, no board can genuinely exercise that responsibility.

The framework put in place defined roles and responsibilities and set periodic reporting to the management body. That is what a governance framework is for: every responsibility with an identifiable owner, and a board that receives information it can decide on.

Incidents: classify before you report

For incidents I defined classification criteria, thresholds and flows consistent with the obligations, integrating them into the incident-management processes already in use rather than adding a new one alongside.

The reason is practical. DORA’s regulatory technical standards on incident reporting (Delegated Regulation (EU) 2025/301) set tight deadlines: the initial notification is due within 4 hours of classifying the incident as major, and in any case within 24 hours of the entity becoming aware of it; the intermediate report within 72 hours of the initial notification; the final report within one month of the latest updated intermediate report. The first deadline runs from classification, capped at 24 hours from awareness. If whoever handles the incident cannot apply the criteria quickly, the deadlines become unreachable exactly when they matter.

ICT providers: a register built almost from scratch

This was the most critical point. The register of information required by Article 28(3) covers all contractual arrangements with ICT third-party service providers, and building it means linking every contract to the services provided and to the functions those services support.

On top of the register sat a methodology to identify the providers critical to the entity, starting from the services that support critical or important functions (not to be confused with the critical ICT third-party providers designated by the European Supervisory Authorities under Article 31), together with a review of the key contractual provisions required by Article 30 and of the exit strategies required by Article 28(8).

In my experience exit strategies are the part most likely to stay on paper. Writing that a provider can be replaced is easy; showing how, how fast and with what impact on the functions is much harder.

Proportionate resilience testing

The programme set up a cycle of operational resilience testing proportionate to the institution’s profile. DORA requires financial entities other than microenterprises to have a testing programme (Article 24); advanced threat-led penetration testing, the TLPT of Article 26, applies to the entities identified by the competent authorities. Starting from what the profile actually requires avoids spending on demanding tests while leaving the basic ones uncovered.

A programme that stays, not a one-off exercise

The readiness work was handed over as a programme the internal team could take on: documentation, registers and processes designed to be maintained over time. That is the difference between a project that closes a scope and an entity that can answer a supervisory request without starting again.

What I would take into a new DORA programme

Start with the provider register. In this case it was the most critical point, and it feeds everything else: without knowing which ICT services support which functions, you cannot identify critical providers, you cannot write credible exit strategies, and you risk misclassifying an incident that starts at a provider.

Test incident classification before you need it. An exercise on a concrete case shows straight away whether the criteria can be applied within the required time.

Do not build a second system. Integrating DORA into the processes that already exist, from incident management to contract management to board reporting, costs less and holds up better than a parallel structure that lives only for compliance.

In short

For a financial entity, the choice between NIS2 and DORA on ICT risk and reporting obligations has already been made: it is DORA. The useful question is how much of what exists can be made demonstrable and how much has to be built. In this case it took five months, a provider register built almost from scratch and a framework designed to be maintained by the internal team. The full case is in the case studies section.

The information on this page is provided for general informational purposes and does not constitute legal advice. Applicability depends on the specific facts, sector and jurisdiction.