Register of Information

Most organisations cannot answer, within a day, which of their suppliers — including their suppliers' suppliers — could stop them from taking payments. The information exists: in contracts, in cloud accounts, in a service catalogue, in the heads of the people who set each arrangement up. It has never been assembled, because nothing forced it to be.

The EU's Digital Operational Resilience Act, which has applied to financial entities since 17 January 2025, forces it. Firms maintain a register of contractual arrangements with ICT third-party service providers, at entity, sub-consolidated and consolidated level, recording what each provider supports, whether that function is critical or important, and the chain of subcontracting beneath it.

The artefact is worth building whether or not a regulator requires it. What the regulation adds is a deadline and a format; what the organisation gets is the map.

Why it matters

Concentration risk is invisible until it is enumerated. Four suppliers that appear independent may run in the same cloud region, use the same identity provider, or depend on the same content delivery network. You cannot see a shared dependency you have not written down, and every resilience argument built on supplier diversity is unfounded until you have.

The register also makes a class of question answerable in the right timeframe. When a provider is breached, "which of our services are affected and which of them are critical" is either a query or a week. When a subcontractor changes, the affected contracts are either a filter or an investigation.

The supervisory layer adds something no single firm can buy: the European Supervisory Authorities published the first designations of critical ICT third-party providers in November 2025, bringing the largest concentrations under direct oversight rather than leaving each customer to assess them alone.

Implementation patterns

• Generate it, do not maintain it. Build the register from the contract management system, the cloud accounts and the service catalogue, so it is a report. A register kept as a spreadsheet is wrong by the next quarter, and wrong in the specific way that matters: a missing subcontractor.
• Classify at creation. Tag each service with its criticality when it is created, so the boundary of the regime is a property of the estate rather than an annual judgement exercise someone repeats from memory.
• Record the function, not just the vendor. "AWS" is not an entry; "payment authorisation runs on AWS eu-central-1, supporting a critical function, with these subprocessors" is.
• Capture the contractual terms that matter as fields: notification window, audit rights, subcontracting consent, exit assistance, data location. These are what a supervisor asks for and what an incident needs.
• Reconcile against reality. Compare the register against observed egress and billing data. Providers appear in cloud bills that never appear in a procurement system, and in a mid-sized estate that delta is routinely 20-40% of the entries — the most useful output of the whole exercise.
• Link it to the exit plan, so that each critical provider's entry names where the tested exit evidence lives.

Industry example

DORA is the clearest instance because the format is prescribed and the deadlines are public: competent authorities were required to report firms' registers to the European Supervisory Authorities by 30 April 2025, and the designation of critical providers followed in November 2025. Firms that had already built a generated supplier inventory reported the submission as a reporting exercise; firms that had not described it as a discovery project, which is the same split seen in every estate-wide inventory question.

Failure scenarios

• The annual spreadsheet. Assembled by email, accurate on the day it is finished, stale immediately, and missing exactly the subcontractor nobody was asked about.
• Vendor-level granularity. An entry for a provider with no mapping to functions, so the register cannot answer which services are affected by anything.
• Narrow criticality classification to reduce the compliance surface, which is precisely what a supervisor examines and which leaves genuinely critical dependencies outside the controls.
• Register without exit evidence. A complete inventory of arrangements whose exit plans have never been tested, which documents the exposure without reducing it.
• Shadow providers. Services procured on a card or inside a product's own integrations, invisible to procurement and therefore to the register, until they appear in an incident.

Trade-offs

The register is a permanent data-maintenance obligation, and it attaches a compliance path to what used to be an engineering decision: adding an analytics provider or a new region now touches the register, the classification and possibly the contract. That is real friction and it is the point of the regime rather than a side effect.

Against it, the inventory is the precondition for every other supplier control. Exit planning, concentration analysis, incident scoping and subcontractor transparency all fail without it, so the cost is better understood as the entry fee for those capabilities than as a reporting burden.

When not to use it

A firm outside scope should not copy the full apparatus. The two parts worth borrowing at any size are the generated supplier inventory and the rehearsed exit — the rest of the machinery exists to satisfy a supervisor, and without one it is overhead.

Within scope, proportionality is written into the regime and is routinely misread. Treating every obligation at the intensity a systemically important institution faces produces a compliance programme that crowds out the resilience work it was meant to cause, which is the most common and most expensive mistake made with this regulation.

Interview question

Q: Your regulator asks which third parties support your critical functions, including their subcontractors, and how you would continue if the largest of them failed. You have a week. What do you do, and what would you build so that next time it is an afternoon?

What a strong answer covers: assembling from systems rather than by survey — contract management, cloud billing, service catalogue, egress data — and reconciling them, because billing reveals providers procurement never saw; mapping to functions rather than to vendors; the criticality classification and the temptation to draw it narrowly; that the subcontractor layer is contractual rather than technical and must be a contract term to be obtainable; and that the exit answer is only credible with tested evidence, so the durable build is a generated register linked to exit rehearsals with dates.

Quick check

Quiz: Why is a register maintained as a spreadsheet worse than useless? — It is accurate on the day it is finished and stale immediately, and its errors concentrate in the subcontractor layer, so it produces confidence about the exact dependency most likely to surprise you.

Flashcard: What must a register entry record beyond the vendor name? — The function supported, whether that function is critical or important, the subcontractors beneath it, and the contractual terms that matter in an incident: notification window, audit rights, exit assistance and data location.