The DORA register of information is the single document that regulators use to see every ICT contract a financial entity depends on, which of those contracts support critical or important functions, and who sits behind each provider in the supply chain. Article 28(3) of Regulation (EU) 2022/2554 makes it mandatory.
Book a scope checkThis guide covers the register template by template, the five places where first-cycle submissions failed, and a six-week build sequence that works for an entity without a dedicated DORA team. The data-collection sheet at the end is the one I use to gather the fields before they go into the formal ITS templates.
Every financial entity in scope of DORA must maintain and update a register of all contractual arrangements for ICT services provided by third parties. That is the obligation in Article 28(3) of Regulation (EU) 2022/2554. The register has to distinguish arrangements that support critical or important functions from those that do not.
The regulation does not define the format. Commission Implementing Regulation (EU) 2024/2956 does. It sets out fifteen templates, each a structured table, which together describe the entity, its contracts, the providers, the supply chains behind those providers, the business functions the ICT services support, and the entity's own assessment of each arrangement.
Competent authorities collect the register at least once a year. The ESAs aggregate the national submissions to identify which ICT providers are critical at EU level, which feeds the oversight framework under Articles 31 to 44. Your register is a regulatory filing, but it is also the data source for an EU-wide map of financial sector ICT dependency.
Article 2 lists twenty categories of financial entity. The main ones are credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, managers of alternative investment funds, UCITS management companies, insurance and reinsurance undertakings, insurance intermediaries above the size threshold, and institutions for occupational retirement provision.
Two points trip entities up.
Proportionality applies to the risk management framework, not to the register. A small payment institution under the simplified framework in Article 16 still maintains a full register. The register obligation sits in Article 28, which applies to every entity in scope.
Groups file once but the register covers every entity. Where a parent maintains the register on behalf of subsidiaries, templates B_01.02 and B_04.01 list every financial entity in the group that uses the ICT services. The parent does not file a consolidated view; it files a register that names each subsidiary against each arrangement.
DORA sets no submission date. Article 28(3) requires three things: that you maintain and update the register at entity level and, where they apply, at sub-consolidated and consolidated level; that you report at least yearly to your competent authority on the number of new arrangements, the categories of ICT third-party service provider, the types of contractual arrangement and the ICT services and functions provided; and that you make the full register, or any section of it, available to the authority on request.
The dates come from the collection, not from the Regulation. The pattern is the same in every market: your competent authority publishes a reference date, you report your position as at that date, and the authority forwards the file to the ESAs for the central register. The reference date and the submission window are national, they are republished each cycle, and they move. Check your own competent authority's published date and work backwards from it. The fieldwork is what takes the time, not the upload.
The ITS organises the register into eight groups. Each group holds one to three templates. The numbering is B_01.01 through B_07.01, plus B_99.01.
B_01.01 identifies the entity that maintains the register, by LEI. B_01.02 lists every financial entity within scope of the register, which for a solo entity is one row and for a group is every subsidiary. B_01.03 lists branches.
Straightforward, unless the group structure has changed during the year. The register reflects 31 December. An entity acquired in November is in; one sold in November is out.
B_02.01 is the master list of every contractual arrangement for ICT services, each with a contractual arrangement reference number that you assign and must keep stable across cycles. B_02.02 holds the detail for each arrangement: the type of ICT service using the ITS taxonomy, start and end dates, notice period, governing law, the country where the service is provided, the country where data is stored, and whether the arrangement supports a critical or important function. B_02.03 covers intra-group arrangements separately.
This is where the register lives or dies. Every other template hangs off the reference numbers assigned here.
B_03.01 names the financial entity signing each arrangement. B_03.02 names the ICT third-party provider signing. B_03.03 handles the intra-group signatories.
The signing entity is not always the entity using the service. A parent may sign a group-wide cloud contract that three subsidiaries use. B_03 captures the signatory; B_04 captures the users.
B_04.01 lists which financial entities make use of each ICT service, which is how a group-wide contract gets attributed to the subsidiaries that rely on it.
B_05.01 identifies every ICT third-party provider, with LEI or EUID, country of headquarters, and type of provider. B_05.02 is the supply chain template: for each ICT service supporting a critical or important function, the subcontractors at rank 2, 3 and beyond.
B_05.02 is where entities discover they do not know their own supply chain. A SaaS provider running on a hyperscaler, using a third-party identity provider, with support outsourced to a fourth company, is four rows minimum.
B_06.01 lists the entity's business functions, each with an identifier, a classification as critical or important or not, and the licensed activity it supports. B_07.01 is the assessment: for each ICT service supporting a critical or important function, the substitutability of the provider, the date of the last audit, the exit plan status, and the entity's reliance on the service.
B_07.01 is the template regulators read most carefully. It is where the entity states, in structured fields, whether it could survive the provider failing.
B_99.01 is titled "Definitions from entities making use of the ICT Services" and it is the one people forget, because B_01 through B_07 counts to fourteen and the ITS has fifteen templates. It describes no contract and no provider. It carries the definitions the reporting entity itself applies, the labels it uses for its own functions and services, so that a supervisor reading the other fourteen templates reads them with the meaning you intended rather than one inferred from a field name.
In practice it is the smallest tab and the last one you complete, once the function names in B_02 and the service descriptions in B_05 have stopped moving. Omit it and the submission is structurally incomplete.
These come from the first two cycles across entities in Germany, Luxembourg and the Netherlands.
Every ICT provider in B_05.01 needs an identifier. The ITS prefers the Legal Entity Identifier. Large providers have one. Mid-size software vendors, regional data centres and specialist consultancies often do not.
An EUID works for EU-registered entities as an alternative. For non-EU providers without an LEI, the provider has to obtain one, or the entity has to use the fallback code structure, which attracts validation queries.
Start the LEI check in week one. A provider takes two to four weeks to obtain an LEI, and the entity cannot force them to.
Article 3(22) defines a critical or important function as one whose disruption would materially impair financial performance, soundness or continuity of services, or compliance with authorisation conditions. The definition is clear. The application is not.
The register asks the entity to classify every business function and then flag every ICT arrangement that supports a critical or important one. Classify too narrowly and the supervisor asks why your core banking platform is not critical. Classify too broadly and B_05.02 and B_07.01 become unmanageable because every arrangement needs supply-chain and assessment detail.
Article 3(22) gives the legal definition and it is abstract. A working test I use: if this function were unavailable for one business day, would we be heading towards a major-incident report? What actually decides that is classification under Article 18 and the reporting thresholds, not the length of the outage. But the question forces the conversation into concrete terms, and the functions where the answer is yes are nearly always the ones that belong in the register.
B_05.02 requires the supply chain behind every critical or important ICT service. Entities learn their rank-2 and rank-3 providers by asking the rank-1 provider, who may not know or may not say.
The contractual lever is Article 30(2)(a), which requires the contract to describe subcontracting conditions. If the contract predates DORA, that clause is probably missing, and the provider has no obligation to disclose.
The practical sequence: list the rank-1 providers, send a structured subcontractor disclosure request to each, and document the ones that refuse. A documented refusal is a finding, not a register gap.
B_02.03 and B_03.03 separate intra-group ICT services from external ones. Entities often omit them, reasoning that the group IT function is not a third party.
It is. If a group IT subsidiary provides core infrastructure to a licensed bank in the same group, that is an ICT third-party arrangement under DORA, with the same register, contract and exit plan obligations. The ESAs made this explicit after the first cycle.
The validation layer rejects registers for mechanical reasons. Common ones: end date before start date, notice period as text instead of days, country codes not in ISO 3166, service type codes not in the ITS taxonomy, LEI format errors, and reference numbers that changed between cycles.
Build a validation step into the collection process. A register that passes the national authority's checker on the first attempt is a register that was validated internally before upload.
This sequence works for an entity of 50 to 500 staff without a dedicated team. It starts twelve weeks before the submission date and leaves six weeks for reconciliation.
Pull every ICT contract from procurement, legal and IT. Expect three lists that do not match. Assign reference numbers now.
Run the business function classification with the COO or equivalent, using the one-day question from the classification section. Map each contract to the functions it supports.
LEI check for every provider. Send LEI requests to the ones without. Send subcontractor disclosure requests for every critical or important arrangement.
Populate B_02.02 from the contracts themselves: dates, notice periods, governing law, service location, data location. This is the slowest week.
Complete B_07.01. Substitutability, last audit, exit plan status. If no exit plan exists for a critical provider, record that honestly and open an action.
Run every template through the national checker if one is published, or against the ITS validation rules. Fix. Resubmit internally. Then upload.
Six weeks of reconciliation follow, because the LEI responses and subcontractor disclosures arrive late.
The formal ITS templates are issued by your competent authority. They are not easy to populate directly, because the data lives in contracts, procurement systems and people's heads before it exists in any structured form.
The sheet below is what sits in front of the ITS templates. One tab per template group, with the fields in plain language, the ITS field code beside each, and a column for the source document. Collect into this; transfer into the ITS templates once the data is clean.
Nine tabs: a README plus one per template group, B_01 through B_07 and B_99. Seven columns per tab: field in plain language, ITS code, source document, owner, value, validated, and the fill-in rule the ITS states for that column.
Download the data-collection sheet (.xlsx)The register is not a filing to be forgotten until next December. Three things depend on it.
Article 29 concentration risk. The register shows which providers support multiple critical functions, which is the starting point for the concentration assessment that Article 29 requires before entering any new arrangement.
Article 28(8) exit strategies. B_07.01 records whether an exit plan exists. A register that shows critical providers without exit plans is a list of findings waiting for the next supervisory review.
Article 30 contract remediation. The register surfaces every contract that predates DORA and lacks the mandatory provisions. That becomes the remediation backlog.
Entities that treat the register as the data layer for third-party risk management get the obligation and the risk framework from one effort. Entities that treat it as a form fill it in twice. The same logic drives the one control matrix across several regulations.
This page is reviewed against the regulation and the published implementing technical standards, including the corrigendum of 19 September 2025. Last reviewed 22 October 2026.
The register is the first deliverable in any DORA third-party risk programme, and the one the regulator sees. If the 2026 cycle was painful, the 2027 one does not have to be.
I built registers of information for a group IT service provider serving Landesbanken, which meant one register covering a dozen licensed entities and several hundred ICT arrangements. The data-collection sheet above is the structure that came out of that.
Download it, run the week-one inventory, and if the classification or the supply chain is where it stalls, book a scope check. If you want the whole framework rather than the register alone, the PECB DORA Lead Manager course covers the ICT third-party risk chapter end to end.
Half an hour on your register: the classification, the supply chain, and what is missing before the next submission window.
Book a scope check