DORA for financial services firms that haven't finished the deadline work

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), entered into force for financial entities in the European Union on 17 January 2025. Many institutions did not achieve the full scope in one go: some of the five pillars were in place on that date and some were not, and the gaps varied per institution from an incomplete register of ICT third parties to a missing testing cadence or an incident classification that did not yet work in line with the regulation. The relevant question is no longer whether you met the deadline. It is which obligations remain a priority under continuous supervision, and how you derive demonstrability of those obligations from programme cadence rather than from a one-off project.

Why DORA is not a 17 January event

There is a persistent misconception that entry into force was the end point. It was the starting point. The regulation is directly applicable law: it applies in full from 17 January 2025, and the European supervisors (the European Supervisory Authorities EBA, ESMA and EIOPA, together the ESAs) along with the national authorities (in the Netherlands De Nederlandsche Bank for the majority of the scope and the Autoriteit Financiële Markten where it is responsible) assess against it from that moment onward. They do not do this once. They do it within the regular supervisory relationship they already maintain with financial entities, with DORA as a new normative framework on top of what was already in place.

The supplementary Regulatory Technical Standards and Implementing Technical Standards (the RTS and ITS) were adopted in 2024 and give substance to the operational requirements: what a register of ICT third parties must look like, how a major incident is classified, which forms of threat-led penetration testing meet the TLPT standard. An institution that met the main regulation but did not take on the detailed implementation via the technical standards does not comply with DORA in practice. That is not a formality. It is the norm.

For a CISO reading this, the key mechanism is this: demonstrability under DORA does not come from a report that sat on the shelf in January 2025. It comes from a programme cadence that shows you have the same level of control on any given Thursday in 2026 or 2027 as the regulation requires. The supervisor does not ask what you delivered before the deadline. It asks what is in place now, when it was last tested, and what the board makes of it.

Which DORA pillars remain a priority?

DORA works with five interconnected packages of obligations. Not all five are equally critical as a priority gap, but all five are needed to be in control at the level the regulation requires. For those who did not finish the deadline work in a single move, this is the order in which priority sits.

ICT risk management (Chapter II). The foundation. The regulation requires an ICT risk management framework that the board adopts and reviews periodically, with a documented line from risk to control, a continuity and recovery architecture that also works under pressure, and an information security policy that carries weight in policy decisions. A gap here blocks the demonstrability of the other four pillars, because they rest on the framework from pillar one. Anyone who has time for only one thing does this.

ICT incident management (Chapter III). Detection, classification, escalation, reporting, evaluation. What matters here is not the incident procedure on paper, but how that procedure connects to the reporting obligation for major ICT-related incidents towards the competent authority, within the deadlines set by the ITS on incident reporting. An institution that cannot classify a major incident within the DORA criteria will miss deadlines at the moment things get messy. That is precisely the moment when you do not want that.

Digital operational resilience testing (Chapter IV). Two levels: a baseline testing programme that all entities must carry out (vulnerability assessments, scenario-based tests, performance tests), and threat-led penetration testing for the entities that fall within the scope of TLPT. The baseline level is underestimated by most institutions: a testing programme that does not connect to your critical functions does not meet the proportionality requirement of Article 24. TLPT is a conversation of its own, with its own preparation cadence of months.

Management of ICT third-party risk (Chapter V). A register of all contractual arrangements with ICT service providers, a classification of which functions under which supplier are critical or important, contractual clauses that meet Article 30, and a specific policy for risk assessment before onboarding a new ICT third party. The register has been the largest work package for many institutions, and it is also the package that becomes outdated the fastest after a one-off population. Demonstrability here is a living register, not a spreadsheet from January 2025.

Information sharing on cyber threats (Chapter VI). The least binding pillar, but part of the regulation nonetheless. Participation in information-sharing arrangements is optional for entities but explicitly encouraged. For most institutions this is a follow-up step once the other four pillars are in place.

The order one through four is deliberate. Pillar one is a precondition, pillar two is what gets tested first under pressure, pillar three is what does not go away on its own, pillar four is what takes the most work to maintain. Anyone who reverses the order and starts at four builds a register that, without the framework from pillar one, does not get the right classifications.

What does the supervisor do if you are not yet fully compliant?

No sanction on day one. That is not how continuous supervision works in the Netherlands. Under the regulation, DNB and the other competent authorities have a hierarchy of supervisory instruments, and they deploy these proportionately. A first signal is a request for information: asking for documentation, the ICT risk management framework, the register of ICT third parties, the test results of the past year. How that request is answered determines whether an entity stays in the usual relationship or comes under more intensive supervision.

A second signal is on-site or off-site inspection: a factual test of whether what is in the documentation also works in the organisation. The same rule that applies to Article 21 of NIS2 surfaces again here: you are not judged on what is missing on paper, you are judged on what is missing beneath the paper reality. A continuity plan that formally exists and has not been tested in two years does not comply. A register of ICT third parties that is formally populated but lacks the critical-function classification does not comply. An incident procedure that formally exists but does not connect to the DORA classification criteria does not comply.

A third signal, if the first two do not lead to sufficient movement, is formal directions or administrative measures. The regulation and the national implementing act provide the basis for this, and the Dutch supervisors have been using these instruments for years on other prudential files. Fines are the final piece, not the starting point, but they exist. And for the management of a financial institution, the reputational effect of a formal direction weighs more heavily than most fine amounts.

The mechanism a CISO should know: the further an institution is from the norm, the more intensive the relationship with the supervisor becomes. That is not a disaster in itself, but it costs capacity you would rather deploy elsewhere. A programme that brings the pillars into order in phases and is at the same time demonstrably in motion is given room. A programme that fell silent after the deadline is not given that room.

How to close the gaps in order

Prioritisation within the five pillars is not about what is easiest, it is about what is most blocking for the demonstrability of the whole. Three shifts that consistently recur in engagements where DORA comes in after the deadline.

One, the ICT risk management framework must work first, not last. In 2024 many institutions gave all their attention to the third-party register, because that was the most tangible deliverable. That is understandable, and it leaves a gap in pillar one that undermines the other four. The framework from Chapter II defines what a critical or important function is, and without that definition the third-party register and the testing programme take the wrong scope. Correcting the order means in practice: update the framework, sharpen the definitions, and then build the other pillars against it.

Two, the incident reporting chain must work under pressure. The ITS on classification and reporting of major incidents gives explicit criteria for when an incident must be reported and within which deadline. A chain that exists on paper but cannot produce the right classification and report within the deadline during a real ICT outage is a chain that will stand out as a gap in the next inspection. Test the chain the way you test a crisis organisation, with a realistic scenario, and keep the outcome somewhere the board can see that it happened.

Three, the third-party register must be alive. A register that was populated in January 2025 and has not been maintained since meets Article 28 for the state at one moment, and not for the state at the moment the supervisor looks. That is a maintenance process, not a population process. It should be embedded in procurement, in architecture and in vendor management, with periodic verification of the contractual clauses from Article 30 for the suppliers that deliver critical or important functions. ENISA has published guidance on the theme of third-party risk management that is usable as a reference framework when setting up that verification cycle.

The division of roles that goes with this is the same as in any mature security programme. The CISO is responsible for the demonstrability of the five functions. The CIO and architects carry the fit within the ICT landscape, and watch whether the DORA requirements do not clash with other quality criteria within the architecture. The board carries the burden of decision on risk acceptance and on the investment that DORA's proportionality clause imposes. A DORA programme without formal board decisions on risk acceptance is not a DORA programme, it is an ICT initiative with a new name.

The test beneath every gap you still have

DORA is designed for financial entities as one coherent package of obligations, not as five separate projects. That means prioritisation between the pillars always happens in context. A gap in pillar one carries through into pillar four. A gap in pillar two becomes visible as soon as pillar three produces a test result that calls for it. A gap in pillar five is only a gap once the other four are already in place.

The practical test beneath every gap an institution still has: can it, on any given Thursday, in a conversation with the supervisor, be credibly explained why the gap is there, how it has been classified, and what the plan is to close it? Not what is missing, but what is being done about it, and on what timeline, and what the board makes of it. That is the position you want to be in. From that position you are given room, and that is the only room continuous supervision structurally gives to an entity that is not yet fully compliant.

The question where most goes wrong is not which pillar is missing. It is which pillar formally exists and does not actually work. An ICT risk management framework that the board signed and is not reflected in policy decisions. A testing programme that is in the annual plan and does not connect to the critical functions from the framework. A register that is complete and has no supplier verification cycle. An incident procedure that names the ITS classification and has not organised its handling around it. With DORA you are not judged on what is missing on paper. You are judged on what is missing beneath the paper reality.