Regulation (EU) 2022/2554 requires financial entities to maintain a register of information covering all contractual arrangements with ICT service providers, and to make it available to the competent authority on request. It sounds like a supplier list. It is not.
What the register actually asks for
The register is maintained at several levels and connects data that in most organisations lives in separate systems:
- The entity - who is the contracting party and where it sits in the group.
- The provider - identification, country of establishment, parent undertaking.
- The contractual arrangement - type, duration, termination notice, governing law.
- The function the service supports, and whether that function is critical or important.
- Subcontracting - the chain below the direct provider, to the depth that matters.
- Location of data processing and storage.
- Substitutability assessment and the existence of an exit strategy.
The operative word is connects. The register does not ask for a list but for the relationship between a contract, the function that contract supports, and the criticality of that function.
Where population stalls
Procurement holds a list of contracts. IT holds a list of systems. Finance holds a list of suppliers being paid. In practice those three do not reconcile: there are systems without contracts, contracts without systems, and payments without either. Populating the register for the first time is usually the first time anyone puts the three lists side by side.
The second common blocker is subcontracting. The direct cloud provider is known. Who provides its infrastructure and where the data physically sits is known far less often, and contracts frequently do not oblige the provider to disclose it.
The third is determining function criticality. Without a BIA, criticality gets assessed ad hoc, per provider rather than per function. That is the wrong direction: the function is critical, and the provider inherits the property.
How not to do it twice
The register overlaps most with three things you already have, or should:
| The register asks for | Already exists in |
|---|---|
| A list of ICT services and systems | The asset register (ISO 27001, measure 2) |
| Function criticality | The business impact analysis (ISO 22301) |
| Provider risk assessment | Third-party risk management (measure 8) |
| Exit strategy | The business continuity plan |
An organisation that keeps those four as one connected set populates the register by running a report. An organisation that keeps them apart populates it by hand, every year, from scratch.
What to do before populating
- Reconcile the three lists. Procurement, IT and finance, on one shared identifier per provider.
- Start from functions, not from suppliers. Determine which functions are critical or important, then attach services to them.
- Check contracts for subcontracting disclosure. Where no such obligation exists, that is a finding in itself.
- Mark where data is missing. An empty field with a justification beats a guess, and is easier to fix in the next cycle.
DORA is the more specific regime for the financial sector, but it does not displace other obligations. The evidence base overlaps almost entirely with the Croatian Cybersecurity Regulation: the same asset register, the same risk register, the same incident records. Do the work once, report it in several directions.
Sources
Not sure where you stand?
Half an hour of conversation, with no obligation. By the end you know what needs doing and in what order.