cyber compliance Archives - SharpenCISOSharpenCISO

The DORA Register of Information: A Practical Guide

If your organization is a financial entity operating in the EU, the DORA register of information isn’t optional paperwork. It’s a legal requirement, and it’s already in force. The Digital Operational Resilience Act, or DORA, became applicable on 17 January 2025. From that date, in-scope firms need a complete, current register of every contractual arrangement they hold with ICT third-party service providers.

That sounds simple on paper. In practice, it’s turned out to be one of the more demanding reporting obligations financial entities have faced in years. The European Banking Authority, or EBA, ran a dry run exercise in 2024 specifically to catch problems before official reporting began. Even so, the issues it found were still showing up in testing well into 2025.

This post walks through what the DORA register of information actually requires. It covers why regulators built it this way, and what the EBA’s own data quality findings suggest your team should double-check before filing.

What Is the DORA Register of Information?

The DORA register of information is a structured inventory of a financial entity’s ICT third-party relationships. It has to be maintained at three levels: entity, sub-consolidated, and consolidated. A standalone firm reports differently than a banking group with multiple subsidiaries. Either way, both need the register ready and accurate.

This isn’t a one-time filing, either. Financial entities must keep the register current on an ongoing basis. From there, they submit it to their competent authority on request. That competent authority then passes the collected registers up to the European Supervisory Authorities, known as the ESAs, for further use.

Scope matters here too. DORA applies broadly across the EU financial sector. It covers banks, insurers, and investment firms. Payment institutions and a long list of other regulated entities fall under it as well. If your organization falls under DORA at all, the register of information obligation almost certainly applies to you.

Why the DORA Register of Information Exists

Regulators didn’t build this reporting requirement just to generate paperwork. Instead, the DORA register of information serves three distinct purposes. Each one shapes what the data actually needs to look like.

First, it lets financial entities monitor their own ICT third-party risk. A complete register makes concentration risk visible. Say five critical business functions all depend on the same cloud provider. That pattern shows up clearly in the data, instead of staying hidden across five separate contract files.

Second, it gives EU competent authorities a supervisory tool. Regulators can review how firms manage ICT and third-party risk without waiting for an incident to surface the gaps.

Third, and perhaps most consequentially, the ESAs use the aggregated registers to designate critical ICT third-party providers. These are often shortened to CTPPs. Once a provider earns that designation, it becomes subject to direct EU-level oversight. In other words, the register of information isn’t just about your firm’s own compliance. It’s also the mechanism that identifies which cloud and tech vendors are systemically important to the entire European financial sector.

What the 2024 Dry Run Revealed

Before official reporting began, the ESAs ran a dry run exercise throughout 2024. Financial entities across the EU submitted test registers as part of it. That gave regulators, and the firms themselves, a chance to find problems before the requirement carried real legal weight.

The dry run wasn’t a minor pilot, either. It included industry workshops, a dedicated reporting template, and a draft taxonomy. It also came with its own data quality checks. The EBA published a summary report afterward, along with a factsheet explaining what the exercise was meant to accomplish.

That preparation mattered, because it surfaced structural issues early. Following the 2024 exercise, the EBA published observations from testing official RoI submissions. The findings described key common issues identified across the industry. In practice, this means firms weren’t just getting individual data points wrong. They were running into recurring, systemic problems with how they structured and validated their registers in the first place.

The Technical Side of the DORA Register of Information

Filing the DORA register of information isn’t a matter of filling in a spreadsheet freely. Instead, the reporting format is tightly specified through a formal technical package.

At the center sits the Implementing Technical Standards, or ITS, on the register of information. These were adopted and published in the EU’s Official Journal. From there, the EBA maintains a full Data Model. That includes a Data Point Model dictionary and an annotated table layout defining every field a firm might need to populate.

Submissions ultimately need to conform to a taxonomy built on XBRL-CSV architecture. Sample files and a full taxonomy package are both available for firms to test against before filing for real. On top of that, the EBA publishes validation rules. It also provides a detailed overview of the technical and business checks it applies to every submission. There’s even a plain CSV reporting package for firms that want a simpler path than full XBRL tooling, along with a conversion tool to move between formats.

This level of technical specification exists for a reason. Registers arrive from hundreds of financial entities, spread across different countries and different internal systems. All of that still has to aggregate into one consistent dataset the ESAs can actually analyze.

Common Pitfalls in DORA Register of Information Reporting

Given how technical the format is, it’s no surprise that data quality has been a recurring theme. The EBA has published explanatory material on the data quality feedback firms receive from validation checks. It also shares sample data quality responses, so firms can see what an actual error report looks like before they get one of their own.

A few patterns stand out from that material. Firms sometimes struggle with correctly categorizing licensed activities, which draws on a dedicated annex listing possible values. Others run into trouble with how sub-consolidated and consolidated registers relate to each other. Group-level reporting introduces dependencies that a single-entity register simply doesn’t have to handle.

The EBA also maintains a running FAQ on register of information reporting, updated as new questions surface. That FAQ is worth treating as a living document rather than a one-time read. It reflects issues the EBA is actually seeing in submitted data, not hypothetical edge cases.

How to Prepare for DORA Register of Information Reporting

If your organization hasn’t yet built a repeatable process for this, a few priorities make the biggest difference.

Start by mapping every ICT third-party contract your organization holds, not just the obvious cloud vendors. DORA’s definition of ICT third-party services is broad. Gaps in your contract inventory become gaps in your register, and those gaps are exactly what supervisors are trained to look for. Next, assign clear ownership for keeping that inventory current. The register isn’t a point-in-time exercise. Contracts change and vendors get replaced, so the register needs to reflect that in near real time.

From there, test early against the EBA’s published validation rules. Don’t wait until a filing deadline to discover a formatting issue you could have caught months earlier. The dry run exercise and the subsequent common-issues report both exist specifically so firms can learn from other people’s mistakes instead of their own. Finally, if your organization already runs other EU compliance programs, look for overlap. The vendor risk assessment work behind ISO 27001 or NIS2 compliance often maps closely onto the third-party data DORA now requires, just in a more structured, reportable format.

The Takeaway

The DORA register of information has moved past the planning stage. It’s a live, binding obligation now, backed by a detailed technical reporting package and a body of real-world data quality findings from the EBA’s own testing. The firms handling it well aren’t the ones treating it as an annual scramble. They’re the ones maintaining an accurate, continuously updated inventory of ICT third-party relationships, validated against the EBA’s published rules well before any filing deadline arrives.

If you haven’t tested your register against the EBA’s validation rules yet, that’s the most useful next step. Everything else in this process builds outward from having that data structured correctly from the start.

Sources: European Banking Authority — Preparations for reporting of DORA registers of information

While many organizations were still waiting for France’s transposition of NIS2, ANSSI published the ReCyF — Référentiel Cyber France (v2.5) in March 2026. This working document is now the regulatory backbone of what’s coming, well before the formal decree lands.

Here’s what you actually need to understand.

1. This is no longer an IT topic — it’s a leadership topic

The ReCyF is explicit about this: digital security governance now falls under the personal responsibility of the executive in charge. They approve the security policy. They answer for any gaps.

Concretely, that governance framework has to include four things: a defined organization, clear roles and responsibilities for digital security, a process for managing compliance, and a formal information security policy (PSSI). That PSSI isn’t a one-off document, either. Your organization has to review it at least once a year, and it must cover, at minimum, encryption use, physical and logical access control, and the review of security measures already in place.

Cybersecurity has moved up to the executive committee. This time, it’s staying there.

2. Are you an “Entité Importante” (EI) or an “Entité Essentielle” (EE)?

This isn’t just a vocabulary question. The first 15 security objectives apply to both categories equally. Objectives 16 through 20 — formal risk analysis, information system audits, dedicated administration, and security supervision — apply only to EEs.

There’s another distinction worth knowing: only essential entities (EE) must designate a named point of contact for ANSSI, responsible for security incidents and all related communications. Important entities (EI) face no such obligation. In short, your EI/EE status doesn’t just affect your paperwork — it directly determines your compliance workload.

3. The structure of the obligations: What vs. How

The ReCyF separates two levels, and the distinction matters:

Security objectives: mandatory. They define what you must achieve.
Acceptable means of compliance: recommended by ANSSI, not mandatory on their own. They define how you can demonstrate that achievement during a control.

Among those means, a valid ISO 27001:2022 certification can demonstrate several objectives at once — governance chief among them. But it only counts for the systems actually covered by the certification’s scope. A certification that covers one business unit doesn’t automatically cover the rest of the organization.

4. The 4 concrete pillars to address

The framework rests on four clear pillars:

Governance: mapping your information systems, defining your security policy, and controlling your supplier ecosystem.
Protection: physical access, architecture, identity management, encryption.
Defense: detecting and responding to incidents.
Resilience: business continuity and disaster recovery plans, crisis management, and regular exercises.

Each pillar maps to a specific set of the ReCyF’s 20 security objectives, and each objective ties back to an article of the NIS2 directive itself. Nothing here is arbitrary — it’s European law translated into operational requirements.

What this actually changes

Many organizations assumed they could wait. The ReCyF closes that option. It sets a precise framework, with requirements that differ by EI/EE status, ANSSI controls that can happen at any time, and named accountability for the executive in charge.

The question is no longer “do we need to comply?” It’s “where do we start?”

Evaluate your maturity in 15 minutes

Want to assess your maturity against the ReCyF ahead of NIS2? SharpenCISO automates multi-framework pre-audits. You get your report and a preliminary action plan in 15 minutes, not weeks.

🌐 www.sharpenciso.com ✉️ contact@sharpenciso.com

#SharpenCISO #GRC #Cybersecurity #Founders #CISO #RSSI #NIS2 #DORA #ISO27001 #NIST #Compliance #SecurityByDesign