DORA: The 5 Most Common Mistakes in the ICT Register of Information and How to Avoid Them

The ICT Register: DORA's most tangible obligation

Regulation (EU) 2022/2554, known as DORA (Digital Operational Resilience Act), has applied in full across the European Union since 17 January 2025 [1]. Of all the obligations it introduces, the Register of Information on third-party ICT service providers, set out in Article 28(3), is the one that first takes shape as a concrete, auditable deliverable: a set of structured data that the financial entity must keep up to date and submit to its competent authority.

The technical detail of that register is not set out directly by DORA, but by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, which establishes the implementing technical standards (ITS) with the standardised register templates [2]. That text arrived after a bumpy process: in 2024 the Commission rejected an initial draft submitted by the European Supervisory Authorities (EBA, ESMA and EIOPA) on grounds of proportionality and technical feasibility, forcing a revision before final adoption [5]. The result is a demanding standard in terms of format, with a set of data templates (codes B_01.01 to B_99.01, grouped into blocks) covering, respectively, the entity and the group, contractual arrangements, signing entities, service users, ICT providers and the subcontracting chain, supported functions, and risk assessments [3].

The first reference cycle had 31 December 2024 as its data date; the exact submission deadline to national competent authorities varied by jurisdiction. The second cycle, with data as at 31 December 2025, was due by 31 March 2026 in jurisdictions such as Luxembourg [7]. The exact deadline for Spain must be confirmed against the circular issued by the Bank of Spain, the CNMV or the DGSFP. Having supported several mid-sized entities through their first two submissions, we have identified a recurring pattern of mistakes that repeats regardless of sector (banking, insurance, investment services) and that can lead to formal requests from the supervisor. We describe them below, along with their root cause and the practical fix.

Mistake 1: filtering the register by "criticality" instead of "ICT link"

Article 28(3) requires declaring all contractual arrangements with ICT third parties, not only those the entity considers critical [1]. In practice, many entities applied their own internal relevance criteria and left out support contracts, software licensing or SaaS subscriptions they regarded as "minor".

Why it happens

The mistake usually stems from confusing two concepts that the standard carefully distinguishes: the scope of declaration (every ICT arrangement, without exception) and the criticality classification (a field within each record, not an entry filter). Both exist in different templates: the universe of providers and contractual arrangements goes in blocks B_02 and B_05; the link to critical or important functions is resolved in B_06.01 and B_07.01 [3].

Consequence

The supervisor can detect the omission by cross-checking the Register against accounting information — invoices and spend by ICT provider — or against the contracts the entity itself holds. A discrepancy of this kind typically results in a request for information and, in the more serious cases, in a sanctioning file once the national infringement regime, currently going through parliamentary proceedings, is finally applied [9].

Practical fix

1. Start from the supplier general ledger and filter by nature of spend (ICT, software, cloud, telecommunications), not by a criticality judgement.
2. Cross-reference that list against the contract repository and recurring purchase orders.
3. Resolve the criticality classification afterwards, as an attribute of the record, not as an exclusion criterion.
4. Document the scoping criteria in an internal procedure, since the supervisor may request it as evidence of data governance.

Mistake 2: declaring only the direct provider and omitting the subcontracting chain

DORA is not limited to the provider with whom the entity signs the contract. Article 28(2)(e) requires that contract to include a subcontractor disclosure clause, and for ICT services that support critical or important functions, the regulatory technical standard on subcontracting requires identifying the full chain — not just the first level — and assessing the risk that a failure at any link could disrupt the service [8]. The B_05.02 template ("ICT service supply chains") of the Register is designed precisely to capture that material subcontracting, regardless of the level of the chain at which it occurs.

Many entities declare only the provider they negotiate with — for example, a SaaS provider — and omit the hyperscaler or data centre that actually delivers the underlying service. The result is an incomplete subcontracting chain that fails to reflect where the operational risk really sits or where the data is actually processed.

Practical fix

• Introduce a subcontractor disclosure and update clause into every new contract (and renegotiate existing ones where possible), aligned with Article 28(2)(e).
• For services supporting critical or important functions, formally request the full subcontracting tree from the provider, including the processing location of each link.
• Prioritise review by spend volume and operational dependency, not just by the provider's name.
• Record the date the subcontracting tree was last confirmed: this is a data point the supervisor may ask for to verify that the register is not a static snapshot.

There is no publicly available, verifiable statistic on how often entities omit level-2 subcontractors. If your organisation has its own internal audit data, it should be cited as such, not presented as a market-wide figure.

Mistake 3: inconsistency between the "critical or important function" flag and the impact analysis

The field that marks an ICT service as supporting a critical or important function in the Register (templates B_06.01 and B_07.01) must be consistent with the business impact analysis (BIA) and with the entity's inventory of critical functions, as required under DORA's ICT risk management framework. Declaring a service as non-critical in the Register when the BIA identifies it as supporting a critical function is a documentary inconsistency that the supervisor can detect relatively easily, since both documents tend to be requested in the same information request.

Practical fix

• Establish a single source of truth for the catalogue of critical and important functions, feeding both the BIA and the Register.
• When a function's classification changes in the BIA, automatically trigger a review of the corresponding field in the Register.
• Assign responsibility for this synchronisation to a specific role (typically the ICT risk or operational risk function), rather than leaving it spread across teams with no clear owner.

Mistake 4: technical fields that fail format validation

Register templates are submitted in the technical format set by the competent authority's reporting instructions and are validated against a Data Point Model and a set of validation rules defined by the ESAs [3][7]. Dates that do not follow the ISO 8601 format, country codes that do not comply with ISO 3166, or processing locations described in generic terms ("Cloud", with no region or provider) are rejected or trigger warnings that delay validation of the submission.

Practical fix

1. Validate the file against the latest published version of the Data Point Model and the ESAs' validation rules well ahead of the deadline, not on the day of submission itself.
2. Standardise date and country-code formats internally in the source system (ERP, CMDB or GRC tool), not only at the point of export.
3. Require cloud providers to specify the exact processing region as a standard contractual clause, avoiding ambiguous descriptions in source documentation.
4. Keep a version history of the submitted file, together with the validation log, as evidence in case of a supervisory request.

Mistake 5: treating the Register as an annual report rather than a living process

The Register is not a deliverable that gets "closed off" once a year ahead of the 31 March deadline. DORA requires it to be kept up to date whenever there is any material contractual change: a renewal, a change of subcontractor, a modification to the service level or to the processing location. Many entities treat it as a static reporting exercise and only review it in the weeks leading up to the annual submission.

Consequence

This creates a mismatch between the Register and the actual state of contracts in force. If the supervisor opens an inspection following a specific incident — which DORA makes more likely by shortening the notification deadlines for major incidents — it may find active contracts that are missing from the Register or that appear with outdated data.

Practical fix

Assign a ICT Register owner (usually the technology or operational risk function) with a defined workflow:

1. Any material contractual change triggers an update to the Register within a defined internal timeframe (for example, 30 calendar days).
2. Periodic review — quarterly is a reasonable cadence — by ICT risk, cross-checking the Register against the current contract repository.
3. Annual validation by internal audit before submission to the supervisor, as a second-line control.

Minimum checklist before the next submission:

• Reconciliation of the universe of declared ICT providers against the supplier general ledger.
• Updated subcontracting tree for every service supporting a critical or important function.
• Consistency between the "critical or important function" field in the Register and the current BIA.
• Technical validation of the file against the Data Point Model and the ESAs' validation rules.
• Sign-off from the Register owner before submission to the competent authority.

The regulatory context in Spain

In Spain, the competent authority for the Register depends on the type of entity: the Bank of Spain (Banco de España) for credit institutions, the CNMV for investment services firms and other securities market participants, and the Directorate-General for Insurance and Pension Funds (Dirección General de Seguros y Fondos de Pensiones, DGSFP) for insurers and pension funds [6]. Each supervisor coordinates the timetable and technical submission channel with the ESAs. The exact deadline for Spain must be confirmed directly with the circular issued by the Bank of Spain, the CNMV or the DGSFP.

One element worth watching closely is the national sanctions regime. A draft Law on the Digitalisation and Modernisation of the Financial Sector (Proyecto de Ley de Digitalización y Modernización del Sector Financiero) is going through parliamentary proceedings to incorporate the regime of infringements and penalties linked to DORA — covering non-compliance in ICT risk management, incident notification, resilience testing and oversight of critical providers. As of this publication, the text is at the parliamentary stage and has not entered into force. Its final approval and effective date must be confirmed in the Official Gazette of the Spanish Parliament (Boletín Oficial de las Cortes Generales) and the Official State Gazette (Boletín Oficial del Estado, BOE).

Conclusion

Of all DORA's obligations, the ICT Register of Information is the one that most quickly exposes the real maturity of an entity's third-party management. It is not a one-off reporting exercise, but the visible outcome of three processes that must operate continuously: the contract inventory, the impact analysis on critical functions, and data governance. Correcting the five mistakes described — poorly filtered scope, an incomplete subcontracting chain, inconsistency with the BIA, technical validation failures and a lack of ongoing governance — does not eliminate the risk of a supervisory request, but it does substantially reduce the likelihood of that request turning into a material finding.

---

Frequently asked questions

What exactly is the DORA Register of Information? It is the register that Article 28(3) of Regulation (EU) 2022/2554 requires every financial entity within the scope of DORA to maintain, detailing all contractual arrangements with third-party ICT service providers. It is structured into a set of templates (codes B_01.01 to B_99.01) defined by Implementing Regulation (EU) 2024/2956 and submitted to the competent authority in the format set by the corresponding reporting instructions.

What is the submission deadline for the Register in 2026 and 2027? For the 2026 cycle, the data reference date is 31 December 2025. In Luxembourg, submission to the CSSF was due by 31 March 2026 [7]. The exact deadline for Spain must be confirmed with the competent supervisor's circular. The scheme for 2027 is likewise not confirmed in this publication.

Do all financial entities have to submit the Register, including microenterprises? Yes. The simplified regime under Article 16 of DORA exempts microenterprises from obligations such as advanced threat-led penetration testing or certain annual internal audits, but it does not exempt them from maintaining and submitting the Register of Information, nor from the ICT third-party risk management obligations.

Who is the competent authority for the Register in Spain? It depends on the type of entity: the Bank of Spain for credit institutions, the CNMV for investment services firms, and the DGSFP for insurers and pension funds. Each publishes its own timetable and submission channel, coordinated by the European Supervisory Authorities.

Is the DORA non-compliance sanctions regime already in force in Spain? As of this publication, no. A draft Law on the Digitalisation and Modernisation of the Financial Sector, which incorporates the Spanish regime of infringements and penalties for DORA non-compliance, is currently going through parliamentary proceedings. Until its final approval, supervisory oversight relies on the supervisor's ordinary powers and on the directly applicable European regulation. The exact procedural status can be confirmed in the Official Gazette of the Spanish Parliament.

How does the Register relate to the ICT subcontracting chain? The Register (template B_05.02) requires documenting the material subcontracting of ICT services, and Article 28(2)(e) of DORA requires including a subcontractor disclosure clause in the main contract. For services that support critical or important functions, the regulatory technical standard on subcontracting further requires identifying the full chain and assessing the risk of each link, not just the direct provider.

Sources

[1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj

[2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024 — https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng

[3] EBA — Implementing Technical Standards to establish the templates for the register of information — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/implementing-technical-standards-establish-templates-register-information

[4] EBA — Digital Operational Resilience Act (supervisión directa) — https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act

[5] EIOPA — ESAs respond to European Commission's rejection of technical standards on registers of information under DORA (15/10/2024) — https://www.eiopa.europa.eu/esas-respond-european-commissions-rejection-technical-standards-registers-information-under-dora-and-2024-10-15_en

[6] DGSFP — Información Reglamento DORA — https://dgsfp.mineco.gob.es/es/Entidades/Paginas/Informaci%C3%B3n-Reglamento-DORA.aspx

[7] CSSF — DORA: Submission timeframe for register of information (11/02/2026) — https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/

[8] Morgan Lewis — Preparing for DORA: Subcontracting ICT Services – Contract Requirements — https://www.morganlewis.com/blogs/sourcingatmorganlewis/2024/07/preparing-for-dora-subcontracting-ict-services-contract-requirements

[9] Ministerio de Economía, Comercio y Empresa — El Gobierno aprueba la ley para la modernización del sector financiero (14/07/2026) — https://portal.mineco.gob.es/es-es/comunicacion/Paginas/ley-modernizaci%C3%B3n-sector-financiero.aspx

[10] EBA — Single Rule Book Q&A 2025_7388 — https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2025_7388

Sources

• [1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• [2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024, por el que se establecen las normas técnicas de ejecución relativas a las plantillas normalizadas del registro de información, EUR-Lex — https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj/eng
• [3] EBA — Implementing Technical Standards to establish the templates for the register of information — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/implementing-technical-standards-establish-templates-register-information
• [4] EBA — Digital Operational Resilience Act (página de supervisión directa) — https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act
• [5] EIOPA — ESAs respond to European Commission's rejection of technical standards on registers of information under DORA (15/10/2024) — https://www.eiopa.europa.eu/esas-respond-european-commissions-rejection-technical-standards-registers-information-under-dora-and-2024-10-15_en
• [6] DGSFP (Ministerio de Economía) — Información Reglamento DORA — https://dgsfp.mineco.gob.es/es/Entidades/Paginas/Informaci%C3%B3n-Reglamento-DORA.aspx
• [7] CSSF — DORA: Submission timeframe for register of information (11/02/2026) — https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/
• [8] Morgan Lewis — Preparing for DORA: Subcontracting ICT Services – Contract Requirements — https://www.morganlewis.com/blogs/sourcingatmorganlewis/2024/07/preparing-for-dora-subcontracting-ict-services-contract-requirements
• [9] Ministerio de Economía, Comercio y Empresa — El Gobierno aprueba la ley para la modernización del sector financiero (14/07/2026) — https://portal.mineco.gob.es/es-es/comunicacion/Paginas/ley-modernizaci%C3%B3n-sector-financiero.aspx
• [10] EBA — Single Rule Book Q&A 2025_7388, Obligation to maintain a register of information for FEs exempt under article 16 — https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2025_7388