)-.jpeg&w=2048&q=75)
When a supervisor opens a review, the document they are most likely to ask for by name is also the one most likely to be incomplete in a way that is easy to prove: the register of every ICT third party the firm depends on. Under DORA this is the Register of Information - a structured, machine-readable list of every contractual arrangement the firm has with an ICT third-party provider.
For a firm supervised by the Central Bank of Ireland, it is not an internal nicety; it is a submission.
The register itself is a solved format, the templates exist. What is hard is making it true: ensuring every ICT third party is actually on it, including the ones that arrived as an AI feature nobody logged.
What the Register of Information is - and is not
First, a distinction that trips firms up, because DORA has two registers and they are not the same document.
The Register of Information, under Article 28(3), is the record of the firm's contractual arrangements with ICT third-party providers - who they are, what they do, which function they support, and whether that function is critical or important.
It is separate from the Article 8 asset register, which is the firm's internal inventory of its ICT assets. One faces outward at the supply chain; the other faces inward at the estate. A firm needs both, and confusing them is a common way to end up with neither done properly.
For this article the subject is the first: the third-party register. The question it answers is not "what do we run" but "who do we depend on, and what did we sign."
What has to be in it
The register is more demanding than a vendor list, because it is built around functions and criticality, not just supplier names. For each ICT third-party arrangement, it captures the provider, the service, the function that service supports, and whether that function is critical or important to the firm.
The part firms most often miss is depth. The register does not stop at your direct providers. Where a subcontractor effectively underpins an ICT service supporting a critical or important function, that subcontractor belongs in the register too.
This is where the AI problem enters: a vendor's AI feature often runs on a model provided by someone else, a sub-processor two steps down - and if that chain supports a critical function, the chain is in scope, not just the vendor you contracted with.
So the register is not a list of contracts. It is a map of dependencies, drawn to the depth at which those dependencies actually run - which is usually deeper than the contract file suggests.
Why the register goes wrong: it only knows what it was told
Here is the failure that makes an otherwise diligent register incomplete. The register is assembled from what the firm knows it has contracted for. It is built from the procurement records, the vendor list, the signed agreements. And that means it inherits a specific blind spot: it cannot include an ICT dependency nobody recorded as one.
The clearest example is the AI feature switched on inside a tool the firm already uses. The tool is on the register, it was contracted years ago. But the AI feature it turned on last quarter introduced a new sub-processor, a model provider now handling data in support of a function that may be critical.
Nothing about that arrival generated a contract or a procurement event, so nothing put it on the register. The register is complete with respect to what was signed, and blind to what was switched on.
A supervisor testing the register does not test it against the contract file, where it will always look consistent. They test it against reality, and reality includes the AI dependencies the contract file never captured.
Building it so it stays true
If the register's weakness is that it only knows what it was told, the fix is to stop relying solely on being told. Building a register that survives scrutiny takes three things beyond the template.
The first is discovery: finding the ICT dependencies that did not arrive through procurement, including the AI features and their sub-processors running inside tools you already have. You cannot register a dependency you have not seen, and the register's completeness is capped by the completeness of the discovery beneath it.
The second is function-mapping: for each dependency found, establishing which business function it supports and whether that function is critical or important - because criticality is what determines the depth of documentation the register requires, and it is a judgement, not a lookup.
The third is maintenance: the register is a point-in-time submission built on a continuously changing estate, so it needs a way to catch the new dependencies that appear between submissions, rather than rebuilding the whole picture once a year under deadline pressure.
I will be straight about what this does and does not settle. The template is the easy part, and plenty of tools will format a register for you. The hard part is the input - knowing that every in-scope dependency, including the AI ones nobody logged, has actually reached the list.
A register formatted perfectly from an incomplete inventory is a well-presented account of a fraction of the supply chain, and it is the fraction that was easy to see.
Frequently asked questions
What is the DORA Register of Information?
Montro's summary: the Register of Information, required under Article 28(3) of DORA, is a structured, machine-readable record of a financial entity's contractual arrangements with its ICT third-party providers - capturing each provider, the service, the function it supports, and whether that function is critical or important.
Competent authorities, including the Central Bank of Ireland for Irish firms, expect it to be maintained and available, which makes its completeness a direct compliance exposure.
How is the Register of Information different from the DORA Article 8 asset register?
They are two different documents facing two different directions. The Article 28(3) Register of Information is the outward-facing record of contractual arrangements with ICT third parties; the Article 8 asset register is the inward-facing inventory of the firm's own ICT assets.
A firm needs both, and treating them as one is a common way to leave gaps in each. This article concerns the third-party register.
Do subcontractors have to be in the Register of Information?
Yes, where they matter. Where a subcontractor effectively underpins an ICT service supporting a critical or important function, it is in scope for the register, not just the direct provider you contracted with.
For AI, this is significant: a vendor's AI feature often runs on a third party's model, and that sub-processor can fall in scope even though you never contracted with it directly.
Why do Registers of Information end up incomplete?
Because they are built from what the firm has contracted for, and inherit the blind spot of procurement. An ICT dependency that arrived without a procurement event, most commonly an AI feature switched on inside an existing tool, bringing a new sub-processor - never generates the record that would put it on the register. The register looks complete against the contract file and incomplete against reality, which is what a supervisor actually tests it against.
