The register of information required by Article 28(3) of DORA looks like an inventory exercise. It is not. It is a structured declaration, in a prescribed format, of every contractual arrangement for the use of ICT services — and because supervisors collect it centrally, errors are visible, comparable across firms, and durable.
We have now built or repaired registers for entities from small payment institutions to mid-size asset managers. The same ten problems recur.
1. Starting from the supplier list instead of the contract base
The register is organised around contractual arrangements, not vendors. One supplier with three contracts is three arrangements. One contract covering four entities appears against each entity. Teams that start from the procurement vendor list produce a register with the right names and the wrong structure, and restructuring it later costs more than building it correctly.
Start from signed contracts. Finance usually has a better list than IT.
2. Leaving intra-group arrangements out
Services provided by a parent or a sister company are ICT third-party services for the purposes of the register. They are in scope, they need contractual documentation, and they are frequently the least documented relationships in the firm, because "it's internal". Supervisors have been explicit about this.
3. Guessing at the functions supported
Each arrangement has to be linked to the functions it supports, and each function has to be assessed for criticality. Most firms have never written down their function map, so this becomes an invented list produced under time pressure by whoever is filling in the spreadsheet.
Do the function mapping first, as a business exercise with the business. It is two or three workshops. Without it, the criticality assessments are unfounded and every downstream field inherits the problem.
4. Declaring everything critical, or nothing
Both happen, and both are read as a failure to assess. If ninety per cent of your arrangements support critical or important functions, you have not assessed; you have hedged. If none do, you are asserting that your firm could operate with all of them gone.
The assessment has to be reasoned and recorded, and the reasoning matters more than the conclusion.
5. Missing the fourth-party chain
For arrangements supporting critical or important functions, you have to identify subcontractors in the chain that effectively provide the service. This is where registers fail most often, because the information is not in your contract — it is in your supplier's.
It has to be requested, and the request takes longer than the deadline allows if you start late. Ask early, ask in writing, and put the answer in the contract at renewal so you never have to ask again.
6. Wrong or missing identifiers
Legal entity identifiers for the firm and its providers, and the EUID where applicable, are mandatory fields with a defined format. A missing or malformed LEI is an automatic validation failure, and for small providers the LEI may not exist yet — in which case someone has to obtain one, which has a lead time and a cost.
Validate identifiers as a separate pass, before you think about content.
7. Treating it as an annual exercise
The register must reflect reality, and it is submitted at least annually with material changes reported as they occur. A register maintained once a year by a spreadsheet owner who has since changed role is, within months, a document that misdescribes the firm to its supervisor.
The fix is procedural, not technical: no ICT contract is signed or renewed without the register being updated in the same workflow. Put it in the procurement checklist.
8. Exit plans that do not exist
Article 28 requires exit strategies for arrangements supporting critical or important functions. The register asks you to say whether one exists. Answering yes when the "exit plan" is a paragraph saying the contract may be terminated with three months' notice is a misstatement, and an easy one for a supervisor to test.
A usable exit plan names the alternative, states how data is extracted and in what format, estimates the time and cost, and has been tested at least on paper. Writing one for your three most concentrated providers is a week of work and it is the item most likely to be examined.
9. Contract terms that predate DORA and were never remediated
Article 30 lists the provisions that must appear in contracts for ICT services, with a longer list for critical or important functions: access, inspection and audit rights, exit and transition support, service level descriptions, incident notification undertakings, location of data processing. Legacy contracts rarely contain them.
The register exposes this. You are declaring, arrangement by arrangement, whether those terms are present. Plan the renegotiation programme before you complete the register, because the register is what makes the gap official.
10. Owning it in the wrong place
We have seen the register owned by procurement, by IT, by legal and by a project manager on contract. It works best owned by the function that already answers to the supervisor — risk or compliance — with IT and procurement as contributors and a named deputy.
The reason is simple: the register is a regulatory declaration. It should be produced by the people who understand what signing a regulatory declaration means.
What a good first pass looks like
For a mid-size financial entity, the honest shape of the work is:
- One week establishing the function map and criticality method with the business
- Two to three weeks assembling the contract base and the identifiers
- Two weeks on criticality assessments, subcontracting chains and data location
- One week on validation, internal review and sign-off
- In parallel, a contract gap analysis that becomes a renegotiation plan
Six to eight weeks, and a register that survives the first question. Firms that compress it into two weeks generally produce a file that passes format validation and fails the first substantive review, which costs more than doing it slowly.
The register is not the point of DORA. But it is the part of DORA your supervisor reads first, so it is the part that sets the tone for everything that follows.