The Register of Information (RoI) is probably the most practical, and also the most labour-intensive, artefact DORA imposes. Art. 28(3) of Regulation (EU) 2022/2554 obliges every in-scope financial entity to maintain a comprehensive register of all contractual arrangements on the use of ICT services by third parties, keep it up to date, and submit it annually to the competent authority. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 standardises the format in 15 data tables.

This article covers:

• The legal anchoring of the RoI in Art. 28 DORA and the supplementary RTS/ITS.
• The 15 data tables of the ESA template, substantively and procedurally.
• Classification of critical and important functions (Art. 3(1)(22) DORA).
• A step-by-step 90-day build-out of an RoI.
• Common implementation mistakes and how to avoid them.

Legal anchors are the main DORA regulation Art. 28-30, Commission Implementing Regulation (EU) 2024/2956, the ESA Joint Guidelines on the Register of Information, and complementary RTS on sub-outsourcing (Commission Delegated Regulation (EU) 2024/1773) and RTS on critical functions (Art. 3(1)(22)). CTPP designation additionally falls under Commission Delegated Regulation (EU) 2024/1502.

The RoI serves several parallel functions, which explains its workload:

• Supervisory instrument: The competent authority (DE: BaFin/Bundesbank, LU: CSSF, AT: FMA, IT: Banca d'Italia/Consob/IVASS) receives the RoI annually in electronic form and uses it for risk analysis, CTPP designation and sector-wide concentration analysis.
• Internal steering tool: The RoI forces financial entities into a disciplined function-to-supplier mapping. Many institutions only discover during the RoI build that they had never properly identified their own critical functions.
• Contractual foundation: The RoI documents which contracts cover which functions, a prerequisite for the Art. 30 DORA conformity check and sub-outsourcing discipline.
• Concentration risk: The competent authority aggregates RoIs sector-wide to identify concentration risks (e.g. 80% of EU asset managers on the same cloud provider).
• CTPP designation: The ESAs use RoI data as input for designating critical third-party providers under Art. 31 DORA.

The complexity of the RoI is not gratuitous; it reflects its multiple functions. A well-run RoI architecture is simultaneously supplier management, risk management, contract management and supervisory reporting in one.

Commission Implementing Regulation (EU) 2024/2956 structures the RoI in 15 tables grouped into three thematic blocks:

• General information (tables B_01 to B_03): identification of the reporting financial entity (LEI, seat, subsidiary structure), overview of all arrangements, total number of ICT third parties.
• Contractual arrangements (tables B_04 to B_07): contract ID, contract type, applicable functions, term, notice periods, governing law, jurisdictions, fees, renewal logic.
• ICT services and functions (tables B_08 to B_15): ICT services classification per Annex III, affected functions (critical/important vs other), substitutability, sub-outsourcing chain, locations of data processing and storage, affected EU Member States and third countries, recovery times, cyber-security requirements.

In total, a full contract description in the RoI runs to around 90-100 data points. For a mid-sized institution with 50-200 ICT contracts that produces an RoI with 4,500 to 20,000 individual data points. Maintenance requires clear data governance, defined data owners and ideally a tool-supported repository rather than a pure Excel solution.

Art. 3(1)(22) DORA defines a critical or important function as a function whose disruption would materially impair financial performance, soundness or operational resilience, or the provision of services whose discontinuation would impact the fulfilment of authorisation requirements or regulatory obligations. Classification is the decisive lever in DORA's scope, because many duties (Art. 28(4), Art. 29, Art. 30(3)) apply only to ICT services supporting critical or important functions.

A proven classification methodology:

1. Function inventory: Collect all business and support functions (typically 50-150 depending on institution size).
2. Impact analysis: Assess the impact of a multi-day disruption on customers, market, supervisor, reputation and finances. Quantitative thresholds (e.g. EUR 1 million daily loss = critical).
3. Regulatory view: Functions used to fulfil licensing obligations are automatically critical.
4. Function-to-contract mapping: Which ICT services support which function? A single contract can support several functions.
5. Inheritance logic: If a function is critical, the ICT services supporting it are generally also critical.

Too narrow a classification reduces DORA workload in the short term but creates supervisory risk (the authority later finds further functions to be critical). Too broad a classification inflates implementation cost. Recommendation: a documented, traceable methodology with an annual review.

A proven 90-day plan for a mid-sized institution:

1. Day 1-15, Methodology and tooling: define the data structure, decide tooling (Excel, GRC tool, dedicated RoI tool), assign data owners per table, define mapping rules.
2. Day 16-30, Function inventory and classification: workshop series with all business areas, build the function inventory, classify critical/important vs other, approval by the risk committee.
3. Day 31-50, Contract inventory: collect all ICT contracts (typically distributed across procurement, IT, compliance and individual business areas), structured capture of the 90-100 data points per contract.
4. Day 51-70, Function-to-contract mapping: which function is supported by which ICT services? Identify gaps (functions without a visible contract) and redundancies.
5. Day 71-85, Quality assurance: data consistency checks, validation against ESA template specifications, sample audits with business areas.
6. Day 86-90, Sign-off and reporting setup: management body approval, preparation of supervisory reporting, documentation of the maintenance cycle (at least annual review).

Realistic effort: 1.5-3 FTE months for the build phase, then 0.3-0.5 FTE for ongoing maintenance. Tooling investments depending on solution: CHF 15,000 to CHF 80,000 per year.

Art. 29 DORA and the supplementary Commission Delegated Regulation (EU) 2024/1773 (RTS on sub-outsourcing) require particular discipline in sub-outsourcing governance. Key duties:

• Prior approval: Sub-outsourcing of critical or important functions requires prior written approval of the financial entity.
• Contractual flow-down: The ICT TPP must pass DORA-compliant contractual terms in full to sub-contractors.
• Concentration analysis: If several critical functions depend on the same sub-sub-supplier, this must be documented in the RoI and assessed in the risk register.
• Third-country specifics: Sub-outsourcing to third countries (especially absent a data-protection adequacy decision) requires additional legal assessment, including a Schrems II-compliant transfer impact assessment.

Art. 30 DORA with its eight mandatory clauses is the contractual anchor. Swiss institutions reviewing EU subsidiaries' ICT contracts typically find gaps in at least three areas: EU supervisor audit rights, service levels with measurable KPIs, and exit clauses with concrete migration commitments. Renegotiations with large cloud providers and SaaS vendors are usually tedious but mostly successful, DORA standard clauses from the hyperscalers (AWS, Microsoft, Google, Oracle) have stabilised since Q2 2024.

Recurring pitfalls from real implementation projects in 2024-2025:

• Function inventory as an afterthought: Starting contract inventory without a clear function inventory means losing oneself in data points without steering logic. Functions first, then contracts.
• RoI as an Excel island: Excel works for initial capture but fails at versioning, multi-user editing, validation and audit trail. By the second supervisory submission at the latest, a tool becomes necessary.
• Sub-outsourcing as a black box: Many ICT TPPs deliver incomplete sub-supplier lists. Recommendation: contractual obligation to provide a quarterly updated sub-supplier list with location data.
• Classification as a one-off: Functions change criticality, a new product, a discontinued line, a new regulatory anchor. Annual classification review is mandatory.
• Unclear data ownership: Who in the organisation owns which of the 15 tables? Without clear RACI, the RoI remains a compliance exercise rather than lived governance.
• Swiss parent excluded: When the EU subsidiary draws ICT services from the Swiss parent, that intra-group "contract" must be captured in the RoI. Often overlooked.

Most mistakes are correctable after the fact, but each correction cycle costs effort and potentially supervisor attention. Early clean methodology pays off.

SIDD supports Swiss institutions and their EU subsidiaries in building the RoI and in ongoing supplier management under DORA. We start with a two-week methodology sprint that defines function inventory, classification and data structure. We then run contract inventory and function-to-contract mapping and deliver a quality-assured RoI in the ESA template.

For contract alignment with Art. 30 DORA we provide clause templates, negotiation playbooks and legal support for renegotiation with large providers. On request we take over ongoing supplier management on a retained basis, integrated with our external CISO service.

For technical resilience assessment of the most important ICT TPPs we deliver penetration tests and vulnerability scans that objectively measure supplier security. Book a first conversation at /kontakt or request a fixed-price quote for the 90-day RoI build at /offerte.