Skip to main content
DORA Auditor

guide

Building your first DORA register of information

A step-by-step guide to drafting the Article 28 register of information, the mistakes we see most, and how to keep it current. Updated with the ITS submission template and 2026 reporting deadline.

DORA Auditor Editorial Team·Published ·Updated

The register of information is one of the most concrete DORA deliverables, and one competent authorities can ask to see. Under Article 28, every in-scope financial entity must maintain a structured record of all its ICT third-party arrangements. Here is how to build a credible first draft without boiling the ocean.

What the register is for

The register is the backbone of DORA's third-party-risk pillar. It gives your board and your supervisor a single, structured view of who you depend on for ICT services, which of those dependencies support critical or important functions, and how each arrangement is governed. It is also the dataset the European Supervisory Authorities use to identify systemically important providers for the oversight framework.

Start with the arrangements that matter

You do not need a perfect register on day one; you need an accurate one that grows. Begin with the arrangements supporting critical or important functions, core banking or payments hosting, key data providers, and anything whose failure would stop you serving clients. Capture, for each:

  • the provider's legal name and identifier (LEI where available),
  • the type of ICT service and the function it supports,
  • whether it supports a critical or important function,
  • contract start and end dates,
  • sub-outsourcing, and
  • whether an exit strategy is documented.

Our TPP register generator builds a first-draft register in the EBA structure from exactly these fields.

The mistakes we see most

  • Treating it as a one-off. The register is a living record. A new SaaS tool or a changed sub-processor means the register changes too.
  • Ignoring sub-outsourcing. Sub-outsourcing is where concentration and exit risk often hide. Record the chain, not just the direct provider.
  • No owner. Without a named owner and a review cadence, the register drifts out of date within a quarter.
  • Skipping concentration analysis. Article 29 expects you to assess concentration risk before entering new arrangements.

Keeping it current

Wire register updates into your procurement and change processes so a new ICT contract cannot go live without a register entry. Review the whole register at least annually, and whenever a critical arrangement changes materially.

The submission format is stricter than a spreadsheet

A first draft can live in a spreadsheet, but the version you eventually submit cannot. Commission Implementing Regulation (EU) 2024/2956 sets out the actual templates: 15 tables grouped into eight areas covering entity information, contractual arrangements, signatories, service usage, ICT providers, functions, and risk assessments. Competent authorities collect registers in xBRL-CSV format built on the EBA's reporting taxonomy, with coded fields (LEI codes for providers, ISO country and currency codes, standardised ICT service-type codes) rather than free text. The register has an annual reference date of 31 December, and entities report to their competent authority by 31 March the following year, so the fields you choose for a first draft are worth mapping straight to the ITS template structure rather than reworking them later.

For a full view of your third-party-risk maturity, and the other four pillars, run the DORA Readiness Score, or read the complete compliance checklist.

Frequently asked questions

Does the DORA register of information have to be in a specific file format?
How often must the register of information be submitted?
What does the register template actually cover?

Sources

Last updated: 17 July 2026.

#third-party-risk#register-of-information

More from the blog