DORA eighteen months on: what actually bites, and what to fix first

What changed once the application date passed

Regulation (EU) 2022/2554 has applied since 17 January 2025, with no transition period. Eighteen months on, the question is no longer whether an entity is in scope, but whether it can prove it. Supervisors have material to work with: two rounds of registers of information, timestamped incident notifications, a first list of critical providers. Reviews turn on observed gaps, not on stated intentions.

The programmes we run converge on one point. The security half of DORA is rarely what derails the project. The cost sits in the register of information and in bringing contracts up to standard: one data exercise and one legal exercise, handed to teams that were never sized to carry them.

The scope is wider than it looks

DORA covers around twenty categories of authorised entity: credit institutions, management companies, insurers, central securities depositories, central counterparties, crypto-asset service providers, crowdfunding platforms. Article 16 opens a simplified framework to certain small entities, without excusing them from the third-party or incident obligations.

The pivot is not the licence category. It is the notion of a critical or important function. Almost every enhanced obligation triggers on that classification: the terms required by Article 30(3), exit strategies, the scope of advanced testing, how deep the subcontracting chain has to be documented. Map too generously and the programme workload explodes; map too narrowly and it will not survive the supervisor's first question. This is the structural decision of the whole exercise: it has to be written down, dated and approved by the management body. In a group it is taken entity by entity — each licence is caught in its own right, and a shared IT function serving three regulated subsidiaries produces three registers and three notification chains.

The register of information is the most underestimated piece of work

Implementing Regulation (EU) 2024/2956 sets the templates and the format: around fifteen linked tables in xBRL-CSV, one row per contractual arrangement rather than per provider, a valid and active LEI in the GLEIF database for the reporting entity and for its direct providers, the countries where the data sits and where it is processed, and the rank of every subcontractor working on a critical function.

None of that is a security exercise. It is a data quality exercise, on a dataset that barely existed anywhere before 2024. The European Supervisory Authorities' dry run drew 1,039 entities in 2024: 93.5% of submissions contained at least one error, and 86% of those errors were nothing more than a mandatory field left empty.

The first official collection took place in spring 2025, against a 31 March reference date; the cycle is now annual, 31 December reference date and submission during the following first quarter. So a register is not a project deliverable, it is a production line: a named owner, reconciliation against procurement and contract records, a consistency check run before submission rather than after rejection.

The most mundane trap is the LEI. Plenty of mid-sized technology suppliers do not have one, obtaining it takes several weeks, and a lapsed identifier produces a hard rejection. Start that collection six months out, not six weeks.

Bringing contracts up to standard is a legal project

Article 30 imposes a baseline set of terms on every ICT services agreement, and a reinforced set in paragraph 3 for those supporting a critical function: quantitative service levels, unrestricted rights of access, inspection and audit, assistance during incidents, participation in resilience testing, notice periods and termination grounds, an exit strategy.

Delegated Regulation (EU) 2025/532 completed the picture on subcontracting. Its history is worth knowing: the Commission rejected the first draft in early 2025 because its Article 5, on monitoring subcontractors, went beyond the mandate the ESAs had been given under Article 30(5). The amended text was adopted on 24 March. In operational terms: you must frame the subcontracting chain before you contract, but the continuous oversight lever the original draft sketched does not exist.

Then there is the negotiation itself. With a hyperscaler or a core banking vendor, you do not negotiate: you take their standard DORA addendum, line it up against Article 30, document the residual gap and carry it into the risk register with an acceptance decision signed at the right level. That is the only defensible posture. The useful work is triage: contracts supporting a critical function first, and within those the ones you cannot exit.

With incidents, the problem is not the form, it is the clock

Delegated Regulation (EU) 2024/1772 sets the classification mechanics. An incident first has to pass a gate — critical services affected, or successful malicious unauthorised access — and then counts as major if the data loss criterion is met on its own, or if at least two of the other materiality criteria are met together. Those criteria carry numbers: more than 10% of clients or more than 100,000 clients affected, downtime beyond two hours on a critical service or an incident lasting more than 24 hours, impact in at least two Member States, costs and losses above EUR 100,000.

The whole chain therefore rests on a classification called under pressure, usually at night, on partial information. The investment that pays is small: an on-call role authorised to classify without waiting for a committee, a decision tree that fits on one page, and a systematic timestamp on the moment of awareness.

The awareness timestamp is the point most often challenged in a review. At exactly what minute did the entity become aware? If the only answer is a ticket whose creation date was overwritten during a handover, the file is weak whatever the technical response was. One simulation a year, crisis committee and lawyer in the room, beats thirty pages of procedure.

What resilience testing demands beyond the annual scan

Article 24(6) requires that all systems supporting critical or important functions be tested at least once a year. Most entities already have an annual penetration test against their exposed perimeter; that is not the same thing. What is needed is a documented methodology, risk-based scoping, genuine independence of the testing function, and findings tracked to closure. Findings left open past their due date are precisely what an inspection will go looking for.

Above that sits threat-led penetration testing, framed by Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025 and applicable since 8 July. Entities designated by their authority run one at least every three years, on production systems, covering several critical functions, driven by threat intelligence produced for the exercise. Internal testers remain possible under conditions, the threat intelligence provider having to be external in that case. The mechanics follow TIBER-EU, aligned with DORA in February 2025.

The difficulty is not technical. It is getting the management body to authorise an adversarial exercise against production, then holding white team discipline for months on end without a leak to the defenders. Firms that fail here fail on governance, not on security.

Direct oversight of critical providers

On 18 November 2025 the European Supervisory Authorities published the first list of critical ICT third-party providers: nineteen firms, spanning hyperscalers, data centre operators, infrastructure providers and specialist financial sector vendors. Each sits under a lead overseer — EBA, EIOPA or ESMA — depending on the sector it predominantly serves, with designation resting on the systemic impact of a failure, the importance of the entities that depend on the provider, the degree of concentration and substitutability. That overseer can demand information, inspect on site, issue recommendations and impose daily penalty payments reaching 1% of average daily worldwide turnover, for six months at a time.

None of this relieves you of anything. If your provider is on the list, your obligations under Articles 28 to 30 are unchanged, and your own authority will still be the one asking you about concentration risk. A question worth nothing until it has been tested: "what do we do if this service is unavailable for six weeks?" calls for a rehearsed plan, not a paragraph.

What a review asks to see

In France the ACPR and the AMF supervise according to the type of entity, the national provisions having been dealt with by Law No. 2025-391 of 30 April 2025. The evidence requested varies little:

• the minutes approving the digital operational resilience strategy and the record of management body training (Article 5);
• the audit report on the ICT risk management framework (Article 6(5));
• the map of critical functions, with its classification method and the date it was approved;
• the register of information in the version actually submitted, and the trail linking each row to a signed contract;
• the incident log, with the awareness timestamp, the classification decision and the notification filings;
• the test plan, the resulting reports and the remediation tracking with its closure dates.

None of this is hard to produce when it was built as you went. All of it is miserable to reconstruct six weeks before an inspection.

A realistic sequence when you are starting late

1. Classify critical or important functions and freeze the list. Three to six weeks: everything else depends on it.
2. In parallel, freeze the inventory of ICT contractual arrangements and start collecting LEIs, the critical path for the register.
3. Get the incident notification chain working within two months: it is the one failure that is immediately visible and dated.
4. Run the contractual gap analysis on critical contracts only, then push the addenda through. Three to five months.
5. Document the annual testing programme and the remediation tracking; prepare for TLPT if your authority has designated you.
6. Put in place the governance: committee, metrics, annual review of the framework, internal audit coverage.

It is not the most elegant sequence. It is the one that cuts exposure earliest.

The real test will be the first major incident

DORA does not reward the organisation that produces the most policies. It rewards the one that knows, at three in the morning, who decides, what gets reported and to whom — and that can show the trail of that decision six months later. Paper compliance is visible at a glance in a register of information: empty columns do not lie.

We run these programmes from scoping critical functions through to submitting the register, and we support them over time in Elyys360, the GRC platform Wavatec publishes. The tool replaces no decision. Classifying a function, deciding what to do with a contract you cannot renegotiate, calling an incident major at three in the morning — those remain business judgements — and they are what the supervisor looks at.