The DORA Register of Information: What the ESAs Actually Check

Ask a compliance team which part of DORA has taken the most work, and many won't point to the risk assessments or the incident reporting rules. They'll point to the Register of Information.

On paper it sounds straightforward. Keep a record of your ICT third-party arrangements. In practice, it's widely reported as one of the harder parts of DORA to get right, and it's an early focus of supervisory attention.

Here's what it actually involves, and why it's harder than it looks.

What the Register of Information is

The Register of Information is a structured record of your firm's contractual arrangements for ICT services. It sits at the centre of DORA's third-party risk regime, and it serves two purposes at once: it supports your own management of ICT third-party risk, and it's the basis for regulatory reporting.

That first purpose is easy to forget. The register isn't only a form you submit. It's meant to be a working record of what your firm depends on, which is why maintaining it well pays off internally, not just at reporting time.

It covers all your ICT service arrangements, not only the ones supporting critical or important functions. More detailed information is required for arrangements that do support those functions, and the register has to distinguish clearly between the two. Where relevant, it also has to be maintained at entity, sub-consolidated and consolidated levels.

And it isn't a single table. Under Commission Implementing Regulation (EU) 2024/2956, which establishes the Register of Information ITS, the register is a relational set of templates covering your organisation, your contractual arrangements, the providers themselves, and the functions those arrangements support. The pieces have to connect to each other correctly, which is where much of the difficulty lives.

Who you actually submit to

One point that trips firms up: you don't submit your register to the European Supervisory Authorities directly.

You report to your National Competent Authority. For an Irish firm, that's the Central Bank of Ireland. Your NCA is your immediate supervisory interface. The ESAs receive register data through the competent authorities and use it for EU-level purposes, including designating the Critical ICT Third-Party Service Providers who fall under direct European oversight.

This reporting isn't a separate filing from maintaining the register. The register is the report. When you submit it to your NCA at least annually, the underlying data is what tells them about the number of new arrangements, the categories of provider, the types of contract, and the ICT services and functions being provided. Which is a large part of why data integrity matters so much. Separately, you're expected to inform your competent authority in good time about planned arrangements that would support a critical or important function, or when an existing function becomes critical or important.

Why the structure is the hard part

The difficulty usually isn't a missing vendor. It's the relationships between the templates.

Your ICT contractual arrangements sit in one template. The critical or important functions they support sit in another. Your organisational profile sits in a third. These are separate tables, linked by identifiers, and they have to map to each other consistently. If the identifiers don't align, the problem surfaces at validation rather than as a gentle request to review.

The 2024 dry run gave a sense of the scale of this. It was a voluntary, best-efforts exercise, so the results aren't a formal DORA compliance failure rate. But of the 947 registers that passed the initial integration checks, only around 6.5% passed all 116 data quality checks. The bulk of the failures came from missing mandatory field values and invalid or mismatched identifiers.

Read carefully, that's an encouraging story for firms that get their house in order early. The failures clustered around structural and data-consistency issues, not deep conceptual misunderstandings. Those are exactly the problems that good tooling and clean processes prevent.

The format is prescribed

Regulatory submission uses a prescribed technical package, built on the EBA's Data Point Model and structured around Legal Entity Identifiers for your firm and for the providers in scope.

It's worth being precise about what this does and doesn't mean. DORA doesn't mandate a particular internal software platform, and it doesn't forbid any particular tool. A firm can maintain its underlying data however it likes, provided it can meet every completeness, consistency, update and reporting requirement. In principle, that includes a spreadsheet.

The catch is at submission. Most NCAs won't take a raw spreadsheet. They require the structured, machine-readable package, and getting from a flat file to a validated submission is where many teams struggle.

It's worth being alert to a false comfort here. Some NCAs provide Excel templates or converters on their portals to help firms bridge that gap, which can leave teams assuming a spreadsheet-based approach is safe end to end. But these tools generally come with the liability disclaimed. If a relational or schema error in the spreadsheet breaks the conversion, the submission fails, and the firm, not the regulator, carries the missed deadline. The template helps you format the data. It doesn't take responsibility for getting the relationships right.

So the real question isn't whether you can hold the data in a spreadsheet. It's whether your approach lets you meet every requirement, and keep meeting them as the arrangements change, all the way through to a submission that passes validation.

The subcontracting chain

The register doesn't stop at your direct providers. Where an ICT service supports a critical or important function, the ITS requires information about the ICT supply chain and subcontractors behind it.

Crucially, DORA doesn't ask you to map every micro-vendor in your provider's supply chain. The threshold is risk-based: you identify the subcontractors whose own disruption would impair your critical or important functions. This is an area firms commonly get wrong in both directions, either mapping nothing beyond the direct provider, or trying to map an infinite chain. Direct providers get captured cleanly, and the material links behind the critical ones are where the real gaps appear.

And to be clear, the register doesn't replace DORA's broader third-party obligations. Due diligence, concentration risk, contractual terms, audit rights, exit strategies and subcontracting management all still stand on their own. The register records the arrangements. It doesn't discharge the duties.

Why this is hard in practice

Step back from the technical detail and the underlying problem is organisational.

The contracts sit with procurement or legal. The knowledge of which systems actually depend on which provider sits with IT. The ownership of risk and the regulatory obligation sits with compliance. The register asks all three to converge into a single, structured, consistent, relationally-linked record, and many firms are assembling it across teams that don't share a system.

Then there's maintenance. A register isn't static. Contracts renew. Providers change their subcontractors. A service that supported a non-critical function last year now underpins a critical one. Under Article 28(3), records of terminated ICT arrangements have to stay on your register for at least five years after the contract ends, so things don't simply drop off when a contract closes. Every one of those changes needs to be reflected, and when the record lives in a manually-updated file, the gap between what's true and what's recorded tends to widen quietly between deadlines.

Maintained continuously, reported at least annually

It's worth separating two obligations that are easy to blur.

The register has to be maintained and kept up to date on an ongoing basis. Separately, specified information has to be reported at least annually, the full register provided on request, and particular collections may be directed by your competent authority.

The continuous maintenance is what makes the periodic reporting manageable. If the record is only pulled together under deadline pressure, it tends to arrive with exactly the consistency gaps that validation is designed to catch. If it's kept current as part of normal operations, reporting becomes a much smaller event.

That's the real shift the register represents: from a document you compile when it's due, to a record you keep because it reflects how your firm actually runs.

What good looks like

The firms finding the register more manageable tend to have one thing in common. They've stopped treating it as a document to assemble and started treating it as a record to maintain.

In practice that means connecting the register to the systems that already hold the underlying information, so that a new contract, a changed subcontractor, or a reclassified function updates the record as part of normal operations rather than triggering a scramble before a deadline.

The question regulators are ultimately asking has moved from "did you assess your providers" to "can you show what you depend on, and who sits behind it." That's an operational question as much as a reporting one. And it's why keeping the register as a live record, rather than an annual compilation, tends to be the difference between a hard reporting cycle and a straightforward one.