Building the DORA register of information

The register of information is not a report you produce once a year. It is a maintained record that decays from the day it is completed. Every new supplier, contract amendment and sub-contractor change moves it out of date, and unlike a periodic return there is no submission event to force a refresh. That is why the build question is not “how do we populate it” but “what keeps it true”.

1. Source it from contracts, not from IT

The instinctive source is the IT asset inventory, and it is the wrong one. The register describes contractual arrangements for ICT services — entities, contracts, functions, sub-contracting chains — and an asset inventory carries none of that reliably. It knows what runs; it does not know who you are contracted with, on what terms, or who they in turn rely on.

That join is worth building deliberately, because it is also what makes the contractual requirements testable: a contract in the register that does not carry the required clauses is a finding you can detect yourself rather than wait to be told about.

2. The critical-or-important test drives everything

The classification of a function as critical or important is the single decision with the widest consequences: it determines which additional contractual requirements apply, the depth of due diligence expected, and the level of supervisory interest in the arrangement.

Two disciplines make it defensible:

• Assess the function, then the provider. Criticality is a property of what the service supports, not of how large the supplier is. A small provider supporting a critical function is a critical arrangement; a large provider supporting a peripheral one is not.
• Record the reasoning, not just the answer. The classification will be challenged, and a register that carries a flag with no rationale cannot defend it. One or two sentences per arrangement is sufficient and is the difference between an answer and an assertion.

3. Sub-contracting depth is where completeness fails

The register reaches beyond your direct counterparty into the chain behind it, and this is reliably the weakest part of any first attempt — because the information is not yours. You are dependent on your provider to tell you who it relies on, and on that provider’s own supplier management to be accurate.

The practical response is contractual rather than analytical: the obligation to disclose and to notify changes in sub-outsourcing belongs in the agreement, with a defined cadence and a defined format. Retrofitting that into an existing contract at renewal is far easier than extracting the information ad hoc every reporting cycle — and a provider that cannot supply it is itself a finding worth recording.

4. Keeping it current

Because there is no periodic submission to force a refresh, the register needs the control pattern that suits a maintained artefact rather than a return:

• A change trigger in the contracting process, so a new or amended ICT arrangement cannot complete without a register entry. This is a gate in procurement, not a task in a reporting calendar.
• A periodic completeness reconciliation against an independent source — typically the accounts payable ledger, which is the one system that knows about every supplier being paid.
• An annual re-test of classifications, because a function’s criticality changes as the business changes even when the contract does not.

The accounts-payable reconciliation is the highest-yield of the three. A supplier being paid for ICT services and absent from the register is a completeness gap that nothing else will surface — and it is a query anyone can run.

5. A worked case

Facts: a firm completes its register from a supplier list maintained by IT, and reconciles nothing.

What is missing: arrangements contracted by business teams outside IT procurement — analytics tools, communications platforms, specialist data services — which are ICT services under the definition but were never on an IT supplier list. Also missing: the sub-contracting layer, which no internal source holds at all.

What the practitioner does: rebuilds the population from the payables ledger filtered for ICT-type spend, joins it to the contract record for terms and dates, and requests sub-contracting disclosure from each provider supporting a critical or important function. The register then has a defensible completeness basis — and the reconciliation that produced it becomes the recurring control rather than a one-off exercise.

FAQ

Related: The register of information · DORA Article 30 contracts · CSSF outsourcing