Most DORA obligations are things you do. The register of information is a thing you hold, and a supervisor can ask for it on any working day without warning.
Article 28(3) of Regulation (EU) 2022/2554 is short and unambiguous. Financial entities maintain and update, at entity level and at sub-consolidated and consolidated levels, a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers. They report it to the competent authority at least yearly, and make it available on request. The Regulation has applied since 17 January 2025.
In Romania the national framework arrived with OUG nr. 14/2026, published in Monitorul Oficial nr. 188 and in force from 11 March 2026. Supervision follows the existing split: the National Bank of Romania for credit institutions, payment institutions, electronic money issuers and certain market infrastructure, the Financial Supervisory Authority for insurers, pension fund administrators, investment firms, intermediaries and crowdfunding service providers. Each entity submits to its own national authority, which consolidates and forwards to the European Supervisory Authorities on an EU-level timetable. That makes your entity deadline a national date, set earlier than the European one and not the same across member states — confirm it and the submission channel with BNR or ASF rather than with a compliance blog, including this one.
The register is a dataset, not a document
The format is set by Commission Implementing Regulation (EU) 2024/2956. It defines fifteen inter-linked templates submitted as an xBRL-CSV report package: a metadata JSON file plus one CSV per template, validated against the published ESA taxonomy. The templates are not independent spreadsheets. They form a relational model across six layers — the reporting entity and its branches, the providers including intra-group ones, the contractual arrangements with their annual cost and exit strategy, the ICT services and their service levels, the functions supported with their critical-or-important classification and the assets and data behind them, and the sub-contracting chain underneath every critical arrangement.
Coded fields do not accept free text. Countries are ISO 3166-1 alpha-2, currencies ISO 4217, service types come from the ESA taxonomy, and every legal entity and provider needs a valid twenty-character LEI. That last requirement is where a surprising amount of work hides: a small Romanian software house that has never reported anything to anyone may not have an LEI at all, and getting one is your problem to chase, not theirs.
Two rules decide most of the quality. One record per distinct contractual arrangement, never one per provider — three separate contracts with the same cloud vendor are three records. And the critical-or-important flag is an output of a business impact analysis, not a field you fill in while building the register. Entities that populate the register first end up asserting a criticality they cannot defend when asked how they reached it.
What the first cycle actually looked like
The European Supervisory Authorities ran a voluntary dry run before the regime went live. Of 947 submissions, 93.5% failed at least one of 116 data-quality checks; only 6.5% passed everything. The ESAs' own reading was not catastrophic — around half of the failing submissions missed five checks or fewer, which suggests the design was broadly right and the data was not. The recurring faults were mundane: wrong identifiers for entities and providers, free text where a drop-down value was required, mandatory fields left blank, and date-format mismatches.
Practitioner summaries of the 2025 live cycle describe the same pattern, with missing or invalid LEIs behind roughly a third of the issues, contracts aggregated by provider, empty sub-outsourcing templates for large cloud vendors, and blank exit-strategy fields on critical arrangements. Those accounts come from consultancies rather than from a supervisor, so treat the proportions as indicative. The direction is not in doubt: supervisors now cross-reference submissions automatically, and an arrangement that appears in your competitor's register but not in yours is visible without anyone reading either one.
The register also feeds a mechanism above your head. The ESAs use the aggregated data to designate Critical ICT Third-Party Providers under Article 31; on 18 November 2025 they published a first list of 19, each assigned a lead overseer. If one of them appears in your register, the Article 30 contractual clauses, the concentration risk and a tested exit strategy stop being paperwork.
Why your IT provider is a critical function
The classification argument that costs the most time is the managed service provider. It is rarely in the business impact analysis, because nothing it does is a business process. It is only support.
CVE-2026-86218 is the reason that reasoning fails. It is a pre-authentication remote code execution flaw in N-able N-central, the on-premises platform many managed service providers use to monitor and administer customer endpoints, scored at the maximum CVSS 10.0. It was exploited in the wild before the fix existed. N-able shipped build 2026.3.1.14 on 6 September 2026 and CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 8 September; a public Metasploit module followed.
One compromised server of that kind does not degrade a service. It grants administrative reach into every endpoint that provider manages, across every customer, at once — which is precisely the definition in Article 3(22): a function whose disruption would materially impair financial performance or the soundness and continuity of services. If a provider holds standing privileged access to systems that support a critical or important function, the arrangement is critical whatever the invoice says.
What to ask before signing, and what to collect every year
Before signature, the register tells you what you will have to be able to report, so ask for it while you still have leverage. The provider's LEI. The full sub-contracting chain for anything supporting a critical or important function, named, not described as "our partners". The countries where data is processed and stored, and where the service itself is provided from. Audit and access rights for you and for your supervisor, written as an obligation rather than as a best-effort cooperation clause. Service levels with a measurable recovery time and recovery point objective. Termination rights and a documented exit plan that says who holds the data on the day you leave and in what format you get it back.
Annually, collect the evidence that the answers are still true: an updated sub-contractor list with changes flagged, the current processing and storage locations, an independent assurance report or the results of a security test, confirmation of the incident-notification route and contact, and a dated statement that the exit plan has been reviewed. Add the two obligations that sit next to the register and get forgotten — the yearly report on new arrangements for the use of ICT services, and the reporting of major ICT-related incidents, alongside the voluntary notification of significant cyber threats where the entity judges them relevant to the financial system, its users or its clients.
One inventory, two views
If you are also an essential or important entity under NIS 2 as transposed by OUG nr. 155/2024, you have a supply-chain security obligation that overlaps heavily with this one and reports to a different authority in a different format. Maintaining two inventories guarantees they will diverge.
The workable arrangement is a single contract and service inventory with the fields both regimes need, and two export views over it. DORA needs the LEI, the critical-or-important flag, the sub-outsourcing chain, cost and exit strategy. NIS 2 needs the supplier's security posture, the contractual security requirements and the evidence you actually collected. Most of the underlying records are identical. Keep them in one place and the annual cycle becomes a query rather than a project.
If you want the register checked against what your estate really contains, and the critical-or-important calls tested rather than asserted, that is the work behind our audit, risk and compliance practice and the NIS 2 and DORA readiness checklist. The assurance a supervisor expects alongside the register — that a critical provider's access path has been tested rather than described — is penetration testing.
Sources: Regulation (EU) 2022/2554 (DORA), Article 28, Commission Implementing Regulation (EU) 2024/2956, ESAs designate critical ICT third-party providers, 18 November 2025, EBA — DORA register of information reporting FAQ.pdf), Huntress — active exploitation of N-able N-central, CISA Known Exploited Vulnerabilities catalogue. The dry-run figures are the ESAs' own; the 2025 live-cycle failure proportions are reported by consultancies rather than by a supervisor and are indicative. We could not confirm a published Romanian entity-level submission deadline on bnr.ro or asf.ro — verify yours directly with your competent authority.
This article is general information, not legal or regulatory advice.