Maintaining DORA registers of information under Article 28

Financial entities subject to Regulation (EU) 2022/2554 have operated under DORA since 17 January 2025. One of the first documents a competent authority requests in a supervisory review is the register of information on ICT third-party arrangements.

Article 28(3) obligations

Article 28(3) requires each financial entity to maintain and update a register at entity level and at sub-consolidated and consolidated levels. The register covers every contractual arrangement for ICT services supplied by an ICT third-party service provider. Contracts must be documented to show which arrangements support critical or important functions and which do not.

The entity must report to the competent authority at least once a year on the number of new arrangements, the categories of providers, the types of contractual arrangements, and the ICT services and functions involved. On request the full register, or specified sections, plus any additional information the authority needs for supervision, must be provided without delay.

Format, submission cycle and data quality

The content and structure are defined in Commission Implementing Regulation (EU) 2024/2956. Submissions use the xBRL-CSV format specified by the ESAs, with a report-package.json metadata file and one CSV per template. Each ICT third-party provider entry requires a valid LEI or equivalent EU-ID.

The 2026 reporting cycle uses 31 December 2025 as the reference date. National competent authorities set their own collection deadlines ahead of the ESA aggregation target around 30 April. In the 2024 dry-run exercise conducted by the ESAs, only around 6 % of submissions passed all validation checks. Failures were driven by missing subcontractor chains, incomplete contract dates, incorrect criticality classifications, and absent LEI values.

Maintaining accuracy for SaaS and cloud contracts

SaaS contracts change frequently through renewals, feature additions, price amendments, and changes in data-processing locations. Sub-processors listed in a provider’s annex can shift without direct notice to every customer. A register that is updated only at contract signature or annual renewal will diverge from the actual estate within months.

Entities that classify every SaaS platform used for a critical function as “supporting critical or important functions” face a higher documentation burden. Exit strategy descriptions, concentration metrics, and the results of due diligence performed under Article 28(2) must sit alongside the basic contract fields. When a provider is later designated a critical ICT third-party provider by the ESAs, the financial entity must already have the relationship recorded at the required granularity.

Evidence and tooling considerations

Many teams still maintain the register in spreadsheets that are exported to the required format only for submission. This approach creates version conflicts and makes it difficult to demonstrate that the register was “maintained and updated” on an ongoing basis rather than reconstructed for the regulator.

Systems that already record contract metadata, sub-contractor flows, service classifications, and change history can feed the register directly. When those systems also retain the supporting artefacts required by the ICT risk management framework, such as due-diligence records and exit-plan references, the cost of producing an accurate, supervisor-ready extract drops. For transfers of register extracts or supporting evidence to authorities or group entities, documented secure channels reduce the chance of ad-hoc email exchanges that later become audit findings.

Financial entities that treat the register as a living component of the ICT risk management framework, rather than an annual compliance artefact, spend less time reconciling data before each submission deadline.

See the contract and control modules for records that support register maintenance.