Your DORA register got accepted. Now supervisors read it.

In 2025, the Dutch AFM saw only 40% of the registers of information it forwarded accepted by the EBA. In 2026, 94% went through. Most compliance teams read that as a job done: the templates work, the identifiers resolve, the file parses. It is the wrong reading. “Accepted” is a statement about the file. It says nothing about whether the register survives the person who now opens it. And someone now opens it: the 19 critical ICT third-party providers were designated from register data, the ACPR has called 2026 “l’année de supervision”, and one of its three inspection themes is the DORA-compliance of your ICT contracts. The register stopped being a reporting chore two filings ago. It is now the supervisor’s map of you.

What “accepted” actually proved

The register of information exists under Article 28(3) of DORA, and its format is fixed by Commission Implementing Regulation (EU) 2024/2956: fifteen templates, one row per contractual arrangement, a valid Legal Entity Identifier for every provider that has one. The first two collections were a format war. In the ESAs’ 2024 dry run, only 6.5% of the 947 registers analysed passed all 116 checks, and 86% of the errors were mandatory data simply left blank. The April 2025 collection was rejected mostly on foreign-key errors: contract references in one template that did not exist in another.

By March 2026 the sector had learned the format. That is the whole meaning of 94%. The validation rules did not soften. The CSSF said so in February: the same checks, applied to more data fields, so that a register accepted the previous year could be rejected this one. What changed is that firms learned to produce a file the machine likes. The machine is not who reads it next.

What you file, what the ESAs derive from it, and what your supervisor now inspects from it.

What the ESAs and your supervisor did with it

Two things happened to your data after it left your portal.

First, the ESAs used it. On 18 November 2025 they designated 19 critical ICT third-party providers under Article 31, and their press release is explicit that the designation drew on data collected through the registers of information. Amazon Web Services, Microsoft, Google Cloud, IBM, SAP, Oracle, Accenture, Capgemini, Equinix, Orange and Deutsche Telekom are on that list. If one of your rows names one of them, the ESAs already know how much of the sector shares that dependency, and so does your national authority.

Second, the national authority read it. The ACPR told the French market in January 2026 exactly what it uses the annual register for: evaluating the third-party risk framework, mapping interdependencies, assessing concentration risk, and reconstructing an incident that arrived through a provider. It described 2025 as a year of accompaniment and 2026 as a year of supervision, with three targeted themes, one of which is a review of ICT contracts for DORA compliance. The AFM says the same in fewer words: it uses the register for risk-based supervision. This is the shift most firms have not made in their heads. The register is no longer something you send to the supervisor. It is what the supervisor prepares from before meeting you.

Five things a supervisor reads before the first meeting

Put yourself on the other side of the table with your own register open. These are the five columns that get read first, because each one is a question the supervisor can answer without asking you.

Concentration. How many of your critical or important functions run through the same provider, and how many through one of the 19? A register that shows one cloud provider under six functions is a concentration finding before anyone has visited.

The subcontracting chain. Delegated Regulation (EU) 2025/532, in force since 22 July 2025, sets out what you must know about subcontractors supporting critical or important functions. If the subcontractor columns are empty for your most important provider, the register says you do not know who actually runs the service.

The critical-or-important tag. This is the classification that turns every other obligation on or off: audit rights, exit strategy, the subcontracting conditions, the tighter contractual clauses. Supervisors read it for two failure modes. Too few functions tagged, which looks like avoidance. Every function tagged, which looks like nobody made a decision.

Identifiers and placeholders. For a legal-person provider the templates take an LEI or an EUID, and nothing else — outside the Union, an LEI only. Where one is genuinely unavailable, the ESAs’ reporting FAQ tells you to fill the field anyway rather than let the file be rejected, and says plainly that doing so “will be highlighted as a data quality issue”. That is why registers carry dummy parent LEIs of the 9999999DUMMY99999999 shape and provider names entered as “not applicable”. They passed validation because they were meant to. They are still the first thing a reviewer circles.

The Article 30 columns. Every row carries fields that describe the contract: term, notice period, governing law, the location of the data, whether the provider is in scope of an exit plan. The ACPR’s 2026 contract review is the register read against the contract itself. Where the register says a clause exists and the contract does not contain it, that is not a data-quality error. It is a finding.

The second-year traps

The 2026 collection also exposed the traps that come with a repeat filing, and they will be there again for the third.

The first is reusing last year’s file. The national authorities that published 2026 guidance (the ACPR, CSSF, NBB, DNB, BaFin and the Central Bank of Ireland among them) asked for a full resubmission on the 31 December 2025 reference date, not a confirmation that nothing changed. A register copied forward carries a reference date, a filename timestamp and a set of field coverage that are all one year stale.

The second is the LEI that lapsed. Registration status is checked against the GLEIF record, and an LEI that was valid in 2025 and not renewed since fails a 2026 check that the same row passed the year before.

The third is the provider count that does not match the contract count. Rows are contractual arrangements, not suppliers. A provider with three contracts is three rows, and a register that collapsed them into one will not reconcile against the contract review when it comes.

This is the same lesson we drew in You’re Not a Bank. DORA Still Applies: the register is where the supervisor’s attention lands first, and an inaccurate one exposes the whole third-party portfolio at once. The difference in 2026 is that the attention has arrived.

The Q4 reconciliation: every register row checked against its contract and its Article 30 clauses.

The next 30 days

The third register is built on the 31 December 2026 reference date, on the same annual rhythm as the first two. Whatever you contract, tag, or leave unresolved between now and then is what gets filed. That makes Q4 the reconciliation window, and the reconciliation is a three-way match: register row, signed contract, Article 30 clause. For each provider supporting a critical or important function, one person confirms the row matches the contract, the contract carries the clauses the row implies, and the subcontractors are named. Where a mismatch appears, fix the contract or fix the row before the reference date, not after the file has been accepted.

For a firm without a dedicated compliance team, that is a month of work for whoever holds the register, and it is where our DORA compliance services usually start. A Virtual CISO who has read your contracts will get through the critical rows in a fortnight; an independent internal audit of the register against the contracts, before the supervisor runs the same test, is the cheapest finding you will ever close.

No supervisor has published a DORA fine yet. DORA leaves penalties to Member States under Article 50, and the enforcement so far has been resubmission demands and reminders. That window is what Q4 is for.