DORA Register of Information Checklist Template

Start about eight weeks before the reference date. The first task records the entity, its LEI, the competent authority, the reference date that every due date counts from, the five people, and three answers that add tasks for a group register, branches abroad and last year’s feedback.

• Set up this year’s register of information — the financial entity and its LEI, the competent authority, the reference date (which every due date counts from), the authority’s deadline if it has published one, whether the register is kept at group level too, whether the entity has branches outside its home country, whether a register was submitted last year, and the five people; later tasks are assigned from these fields
• Confirm the levels and the arrangements in scope — the register covers every contractual arrangement for ICT services from ICT third-party service providers, intra-group providers included, and marks those that support critical or important functions; agree which entities and levels are in this run
• Read the authority’s instructions for this year’s submission — the window, the portal, the file format and taxonomy version it names, the naming rules for the file and any changes since last year; check the page again in January
• Start from last year’s accepted register and its feedback — the file the authority accepted, the validation and data quality feedback it sent, and the fixes still open, so the same errors are not made again
• Agree the data owners and the collection timetable — who supplies the contract, provider, function and assessment data, in what form and by which date, so the register can be frozen just after the reference date

Templates B_01.01 to B_01.03 describe who maintains the register, the entities in it and their branches abroad. A group register adds the entities in the consolidation.

• Record the entity data for templates B_01.01 and B_01.02 — the LEI, name, country, type of entity, competent authority, direct parent undertaking and the value of total assets, reported as Annex IV of the implementing regulation says for that type of entity
• Check the entity’s LEI is valid and active — look the LEI up in GLEIF and renew it before the reference date if it has lapsed; the authority needs a valid LEI for the entity that submits
• Record each branch outside the home country in template B_01.03 — a unique code for each branch, its head office’s LEI, its name and its country; branches are not financial entities but part of their head office
• List the entities in the consolidation — every financial entity and ICT intra-group service provider in the sub-group or group, with its LEI, following the sectoral rules the parent uses to decide what is consolidated

Every contractual arrangement for ICT services goes in the register, not only the ones that support critical or important functions. Templates B_02 to B_04 hold the contract data and who signs and uses each service.

• Pull every contractual arrangement for ICT services from the contract inventory — contracts, orders and intra-group agreements for ICT services, including cloud, software, data and support services bought by business teams, each with a unique reference number used the same way across the group
• Record the general and specific contract data for templates B_02.01 and B_02.02 — type of arrangement, any overarching arrangement, annual expense or estimated cost for the past year and its currency, start and end dates, both sides’ notice periods, the country of governing law, the country of provision, whether data is stored, where it is stored and processed, how sensitive it is and the level of reliance on the service
• Give each ICT service its type from Annex III — one of the 19 types, from S01 ICT project management to S19 cloud software as a service; where one contract covers several types, add a row for each
• Record who signs and who uses each service (B_03.01, B_03.02 and B_04.01) — the entity that signed each arrangement, the provider that signed it, and every entity, or branch, that uses the services under it
• Link intra-group arrangements to the external contracts behind them (B_02.03 and B_03.03) — where a group company provides ICT services to others, record its arrangements and the reference numbers of the external contracts its services rely on
• Record arrangements that ended or were terminated, with the reason — the reason from the closed list in B_02.02 for each arrangement that ended or was terminated, so the register shows what changed since last year

Template B_05.01 identifies every direct provider and subcontractor, and B_05.02 the supply chain behind each service. Missing or wrong identifiers were among the common errors the ESAs found in the 2025 registers.

• Record each direct ICT third-party service provider in template B_05.01 — legal name, type of person, country of headquarters, total annual expense or estimated cost and its currency, and the identifier and type of code for each provider
• Get a valid LEI or EUID for every provider that is a legal person — an LEI or the EUID, and both where available; a provider established outside the EU needs an LEI; other codes are only for individuals acting in a business capacity
• Identify the ultimate parent undertaking of each provider — the ultimate parent’s identifier in B_05.01, which the ESAs use to group providers that belong to the same group
• Map the supply chain for services that support critical or important functions (B_05.02) — each subcontractor that effectively underpins those services, with its rank: the direct provider is always rank 1 and each subcontractor higher than 1
• Collect identifiers for those subcontractors through the direct provider — a valid LEI or EUID for each subcontractor in those chains, obtained through the direct provider, except for individuals acting in a business capacity

Template B_06.01 lists the functions the ICT services support and whether each is critical or important. B_07.01 records the assessment of each service that supports one.

• List the functions the ICT services support (B_06.01) — a function identifier starting with F, the function’s name, the licensed activity it belongs to from Annex II, and the entity that performs it
• Confirm whether each function is critical or important — the yes or no, the reasons and the date of the last assessment, using DORA’s definition of a critical or important function
• Record the recovery time and recovery point objectives of each function — in hours, as the business continuity plans set them, and the impact of discontinuing each function
• Link each ICT service to the functions it supports — every service that supports a critical or important function marked as such, so the contract data and the function list agree
• Record the assessment of each service that supports a critical or important function (B_07.01) — substitutability of the provider and the reason if it is hard to replace, the date of the last audit, whether an exit plan exists, whether the service could be brought back in house, the impact of stopping it, and any alternative providers

Freeze the data as at the reference date, build the file in the format the authority names and check it against the ESAs’ validation rules before anyone signs it off.

• Freeze the register as at the reference date — add the arrangements signed and remove the ones ended in the last weeks before the reference date, then keep a dated copy of the data
• Complete template B_99.01 and check every closed list — the terms used in the closed lists and classification systems, and every drop-down value checked against the ESAs’ list of possible values
• Build the file in the format the authority names — check the authority’s page again for any change, then build the reporting package with the taxonomy version and file naming it asks for
• Run the ESAs’ validation rules and fix every error — the technical checks, validation rules and business checks the EBA publishes for the register, run in your tool before the file goes to the authority
• Check the entity-level data agrees with the group register — the entries for each entity in the consolidation match the sub-consolidated and consolidated register, and the reference numbers are the same at every level
• Check the content makes sense, not only that it passes — no dummy identifiers or generic provider names, expenses in the right currency, dates in the right year and no contract missing because a business team bought it

The approver named on the first task signs the register off before it is submitted. The checklist halts here until they decide.

• Prepare the sign-off pack — the number of arrangements and providers, the services supporting critical or important functions, changes since last year, identifier gaps, validation results and open issues
• Approve the register for submission — the approver records the decision and any conditions; nothing after this task can be completed until it is done
• Rework the register and return it for sign-off — fix what the approver raised, run the validation rules again, then ask the approver to change the decision to Approved and complete the sign-off again

Submit early in the authority’s window to leave time for corrections. A rejected file adds two tasks to correct and resend it; data quality feedback later in the spring adds one more.

• Submit the register in the authority’s window — upload the signed-off file through the authority’s portal, early in the window, and keep the receipt
• Read the validation feedback on the file — the portal’s and the ESAs’ technical validation feedback: accepted, or rejected with the errors listed
• Correct the errors in the rejected file — fix each error at its source, not only in the file, and run the validation rules again
• Resubmit the corrected file before the window closes — upload the corrected file, keep the new receipt and read the feedback again
• Record the accepted submission — the final file, the receipt and the acceptance kept with this checklist as the record of the year’s submission
• Check for data quality feedback on the register — feedback on the content of the data, which can come weeks after the file was accepted
• Answer the data quality feedback and resubmit if asked — correct the data the feedback names, resubmit if the authority asks for it, and carry the fixes into the live register

The register is kept up to date all year, not only at the reference date. These tasks are checkpoints through the year until the next run starts.

• Tell the authority about planned arrangements for critical or important functions — each planned contractual arrangement for ICT services supporting a critical or important function, and each function that has become critical or important, reported in a timely manner
• Update the register for new, changed and ended arrangements — each new arrangement added when it is signed, changes recorded, and ended arrangements given their reason, so the register is current between reference dates
• Keep the full register ready to send on request — the authority can ask for the full register or specified sections at any time, along with other information it needs to supervise the entity
• Review the register for errors and gaps — a mid-year check of the data against the contract inventory and the function list, with errors corrected promptly
• Hand over to next year’s run — lessons from this year, open identifier and data gaps, and the people for the next run, which starts about eight weeks before the next reference date