The second DORA collection of the register of information closed on 31 March 2026. Two weeks before that deadline, the CSSF reported that only 40% of the Luxembourg entities required to file had done so. The register is now an annual habit, on a 31 December reference date, with supervisory quality checks in the weeks that follow. This post sets out what the 2026 round looked like for investment fund managers, why registers get refused, and what to keep current between now and the 2027 window so that next spring is a confirmation rather than a rebuild.
What the 2026 collection looked like
The CSSF opened its eDesk portal for the register of information on 11 February 2026 and set the submission window from that date to 31 March 2026, with 31 December 2025 as the reference date: every contractual arrangement on ICT services contracted by that date had to be in the file (CSSF, 11 February 2026). The scope covered the financial entities subject to DORA under CSSF supervision, investment fund managers included, with a later 30 June date for third-country branches of credit institutions (CSSF, 17 March 2026).
Two practical prerequisites caught entities out in the first round and were restated for the second: the Legal Entity Identifier has to be communicated to the CSSF beforehand, and at least one employee needs the "DORA Reporting" role in eDesk. The file itself is a set of plain CSV files in a zip with a predefined folder structure, described in the CSSF submission guide.
Then the number that should stay in mind.
Two weeks before the deadline, 40% of the entities required to file had done so. The CSSF asked firms to keep people available through April for the ESA validation checks, with refused registers to be corrected and resubmitted before the end of that month. CSSF update, 17 March 2026.
In other words, the deadline was 31 March, but the work ran into May for anyone whose file did not pass first time (CSSF, 17 March 2026).
One nuance for firms with entities in several jurisdictions: the scope of the 2026 round was not identical everywhere. Belgium's FSMA, for example, ran a limited update where only a subset of entities had to submit and unchanged registers could simply be confirmed (FSMA, 17 February 2026). The CSSF ran a full collection. A group-level register is not a Luxembourg filing until it has been checked against the CSSF's own rules.
Why registers get refused
The register is not a narrative document. It is fifteen linked templates in which the same provider, contract, function and entity must be identified consistently, and the validation layers check exactly that consistency. The ESAs' dry run in 2024, on registers submitted by almost 1,000 financial entities across the EU, gave the clearest public picture of where files break: 6.5% of the registers passed all 116 data quality checks, and half of the rest failed fewer than five of them (ESAs, 17 December 2024). Most refused registers, then, are not wrong in substance. They fail on a handful of cross-references, and every one of those has to be found, fixed and re-filed within the resubmission window.
The CSSF publishes a dedicated guide to its error messages for that reason. Reading it before the window opens, rather than after the first refusal, is the cheapest preparation available.
The register is a record, not a filing
The underlying problem is structural, and it is the same one on most compliance desks. The register of information is prepared once a year for the filing, while the information it draws on lives elsewhere and moves all year: the business impact analysis in a spreadsheet, the ICT risk register in another, incidents in a mailbox, third-party contracts and due diligence in the delegate files. Each of those is current on the day it was updated. They are rarely current together, and the register is where the differences surface, as validation errors, at the worst possible moment.
Treating the register as a living record changes the shape of the work. A new ICT contract is entered when it is signed, not rediscovered in February. A provider that is also a delegate is one provider, with one file, in both registers. The critical or important function assessment and the register agree because they are the same data. The annual collection then becomes what the supervisors intend it to be: an extract of a record that already exists, on a reference date.
A short checklist for 2027
The CSSF has not yet published the 2027 window as this post goes out; the exercise repeats every year on a 31 December reference date, so plan on a first-quarter collection and watch the CSSF news page for the dates.
- Confirm the plumbing now. LEI communicated to the CSSF, the "DORA Reporting" role assigned to a named person and a deputy, eDesk access tested.
- Reconcile the register with the delegate and provider files quarterly. Every ICT provider in the register should exist in the oversight record, and every new ICT contract signed after 31 December 2025 should already be entered.
- Run the 2026 error guide against your own file. The CSSF guide lists the checks that refused registers last time. Most are cross-reference errors that can be found in advance.
- Keep the reference-date discipline. Contracts in force on 31 December 2026 belong in the 2027 file; a contract signed in January 2027 does not, however tempting it is to include it.
- Plan people for April, not just March. The ESA validation runs after the deadline; the person who can fix and refile needs to be available then.
Where Klavius fits
Klavius starts DORA from the register you already built. It imports the Register of Information and populates the connected operating sections, the business impact analysis, the critical or important functions, the third-party register, the ICT risks and the incident structure, with the sourcing shown for every entry. The provider file connects to Delegate Oversight, so a delegate that is also an ICT provider is one record rather than two. Officers review, adjust and sign off; nothing is filed by the platform on its own. If the 2026 round was a rebuild, the DORA Operating Baseline is the way to make 2027 a confirmation.
Sources
- CSSF, DORA: submission timeframe for register of information, eDesk portal open as of 11 February 2026, 11 February 2026.
- CSSF, DORA: Register of Information collection, update, 17 March 2026.
- CSSF, Guide concerning the submission of DORA Register of information.
- CSSF, Guidance for interpretation and resolution of error messages related to the submission of the DORA register.
- ESAs, The dry run exercise shows the goal of reporting registers of information in 2025 within reach, 17 December 2024.
- FSMA, DORA register of information: limited update in 2026, 17 February 2026.