The DORA register of information — getting it right, and keeping it right
The register looks like a reporting exercise and behaves like a legal one. Most of what goes wrong traces back to contracts that say something different from what the register says. We work on both sides at once.
First hour’s on us. No commitment.
What you get
- A register that reconciles with your contracts, your entity structure and your function mapping
- A documented critical-or-important assessment for each function, since that drives which arrangements carry the heavier contractual requirements
- Identifier hygiene — LEIs, EUIDs and the subcontracting chains that submissions most often fail on
- A maintenance routine so the register stays current between submissions rather than being rebuilt each year
- Contract fixes where the register has exposed a gap, which it usually does
How it works
- Intake, 45 minutes. Where you are, what your supervisor has asked for. Free.
- Reconciliation, two to four weeks. Contracts against register against function mapping.
- The fix list. What to correct in the register, and what to renegotiate in the contracts.
What the register actually is
Article 28(3) of DORA requires every financial entity to maintain a register of information on all contractual arrangements for the use of ICT services provided by third-party providers. It is submitted to the national competent authority — Finansinspektionen in Sweden — which passes it to the European Supervisory Authorities. The data feeds the designation of critical ICT third-party providers, who then come under direct EU oversight.
It is not a single list. It is a set of linked tables covering the entities in scope, each contractual arrangement, each provider, the ICT services supplied, the functions they support, and the subcontracting chains behind them. The tables reference each other through prescribed identifiers, and a mismatch in one propagates through the rest.
Why submissions get rejected
Identifier problems. Missing or lapsed LEIs, providers identified inconsistently across tables, subcontractors without valid identifiers. This is the single most common cause and the most avoidable.
Broken references. An arrangement pointing at a provider that does not appear in the provider table, or a function referenced but never defined.
Scope errors. Treating the register as an outsourcing register. DORA covers all ICT services, not only what your outsourcing policy classifies as outsourcing — which usually means the register should be considerably longer than the first draft.
Entity structure. Group submissions where the entities in scope, the reporting entity and the contracting entity are not consistently distinguished.
Contradiction with the contract. The register says the service supports a critical or important function; the contract lacks the Article 30(3) clauses that would then be required. Or the register names a data processing location the contract does not permit. This is the failure that matters most, because fixing the register does not fix it.
The critical-or-important assessment underneath it
Almost every consequential field in the register depends on whether an arrangement supports a critical or important function. That is not a technical judgement about system uptime. It is an assessment of what a disruption would do to your ability to meet your regulatory obligations and to maintain continuity of service.
Supervisors ask about this early, and they ask for reasoning. An assessment that was made once in a workshop and never written down is difficult to defend two years later, and it is what determines which of your contracts carry the full Article 30(3) list — audit and access rights, exit strategies, transition periods, notification duties, service level targets.
Keeping it current
The register is a live obligation, not an annual submission. New contracts, renewals, changed subcontractors, new processing locations and reclassified functions all change it. The organisations that find this manageable are the ones that attached register maintenance to their contract lifecycle — a step in procurement rather than a project in Q1.
Frequently asked questions
Does every ICT contract go in, including small SaaS tools?
The scope is contractual arrangements for the use of ICT services, which is broader than most first drafts assume. Small tools are frequently in scope. What varies with criticality is the depth of the requirements, not whether the arrangement is registered.
Do we need LEIs for our providers?
Providers are identified with a prescribed identifier, and the LEI is the primary one. Chasing these from providers takes longer than people expect — start early.
How far down the subcontracting chain do we need to go?
Far enough to describe the chain supporting critical or important functions. This is where most of the effort goes, and where provider cooperation matters. It is also a good argument for building the right clauses into contracts now.
Our submission was rejected. What now?
Work back from the validation errors to the underlying cause. In our experience the technical fix is quick; the question worth asking is whether the error revealed a contract gap.
Can you build the register for us?
We work with your team on the legal side — scope, function classification, contract reconciliation and the reasoning behind each judgement. The data assembly usually sits better with the people who hold the contracts.
Where to start
If you have a register already, the fastest useful step is reconciling it against a sample of your contracts. That usually tells you within a week whether you have a reporting problem or a contract problem.
Who you’ll work with
Fidan Ibrahimzada, Legal Counsel for AI and technology law, leads this work. She advises companies on AI regulation, data protection and technology contracts, and previously led the legal department of a commercial law firm. She holds an LL.M. in European Business Law from Lund University. Lawgent is Sweden’s first law firm dedicated to AI and EU regulation — meet the team.