DORA turns ICT contract data into a maintained risk register

The register is a relationship model

DORA Article 28 requires more than an inventory of supplier names. The implementing regulation turns the register of information into a connected model of the financial entity, each contractual arrangement, the ICT services received, the business functions those services support, and the providers involved. At group level, the same logic must work across entity, sub-consolidated, and consolidated views. A flat vendor table can hold names and renewal dates, but it cannot reliably answer which contractual chain supports a critical or important function.

The templates also separate direct contractual relationships from service delivery relationships. That distinction matters when an intragroup provider, an external ICT provider, and a subcontractor all participate in the same service. The regulation requires direct providers to be recorded and extends the subcontractor view to parties that effectively underpin ICT services supporting critical or important functions, or material parts of them. The operational unit is therefore the service relationship in context, not the supplier record in isolation.

Identifiers and reference keys carry the control

The annexed templates use identifiers and reference numbers so the records can be joined. Legal Entity Identifiers or European Unique Identifiers may identify relevant parties, while contractual arrangements, ICT services, functions, and provider relationships receive their own references. This is not administrative decoration. Without stable keys, a team cannot reconcile a contract amendment, a renamed service, a legal-entity change, and a newly disclosed subcontractor without producing duplicate or contradictory records.

A buyer should test whether a platform preserves those links when facts change. The useful demonstration is not a polished supplier profile. It is a controlled update: change the provider entity on one arrangement, add a supporting subcontractor, alter the function classification, and show which records, approvals, and exports are affected. The evidence should identify who changed the record, the source used, the effective date, the validation performed, and any unresolved conflict.

Maintenance is an operating obligation

The implementing regulation says information in the register must be accurate and consistent, subject to regular review, and corrected without undue delay when errors are found. That language makes freshness and exception handling part of the control. An annual data collection exercise may populate a register, but it does not by itself demonstrate that contract events, function changes, provider restructurings, or new subcontracting relationships reach the record in time.

Teams should map the events that can make a register stale and assign an accountable source for each one. Procurement may own executed amendments, service owners may own function criticality, legal may interpret contractual scope, and risk teams may validate provider and subcontractor relationships. Technology can route and reconcile those inputs, but it cannot resolve an unclear contract or assign criticality without accountable judgment. Buyers should ask how the system exposes missing links and conflicting assertions instead of silently selecting one.

What evidence should enter a buying decision

A credible evaluation starts with the required templates and traces a representative relationship through them. The test should include multiple legal entities, more than one contract, a service supporting a critical or important function, an indirect provider, and a mid-cycle change. Teams can then examine field coverage, relationship integrity, import and export behavior, validation rules, permissions, version history, and the treatment of incomplete data. A DORA-labelled dashboard is not evidence that the underlying register can be maintained.

The regulation establishes the record structure and maintenance expectations; it does not certify a particular product or guarantee that a populated register is complete. Product documentation can support a documented-capability claim, while configuration review and a representative workflow test provide stronger implementation evidence. The final question remains organizational: can the financial entity explain each relationship, correct it promptly, and produce a coherent register from governed sources when supervisors request it?

What we will watch next

Third Party Current will watch for later primary-source evidence that changes the maintained company, capability, or standards record. The next useful evidence may include implementation documentation, release details, regulator findings, corrected methods, product packaging, customer-observable workflow, or a subsequent company statement. Until then, the dated source and its stated boundary remain attached to this analysis.