What the Register Records

The register records ICT third-party arrangements, meaning the deals under which an outside provider supplies ICT services to a financial entity. For each arrangement, the register should let a reader answer a short chain of questions: who is the provider, what service is supplied, which business function depends on that service, under what contract, involving what data, and from which locations. If any link in that chain is missing, the arrangement is only partly recorded, and the missing link is usually the one that matters in a disruption. A provider name without a function tells a supervisor nothing about impact. A function without a provider tells an incident team nobody to call.

Scope matters as much as detail. The register is about ICT third-party service provision, not about every supplier an entity pays. Cleaning, catering, and general office supplies do not belong here, however important they are operationally. What belongs is the ICT layer: infrastructure, platforms, software, data services, connectivity, and support arrangements that keep those services running. Drawing that boundary consistently is the first judgement a register owner makes, and it should be written down so different teams do not draw it differently.

A vendor list answers who the entity pays. A register answers how the entity operates. The difference shows up as soon as something goes wrong. Imagine a customer portal that stops responding. A vendor list points to several technology suppliers, but it does not say which one runs the portal, which one hosts its data, which one provides the login service, or which contract covers each piece. An arrangement record does. It ties the service to the function, so the incident team can work out what customers lose, which provider to contact first, and which contractual terms govern the response.

Provider identity comes first, and it needs to be precise enough to distinguish a group parent from the subsidiary that actually delivers the service. Entity and branch information, covered in the next guide, gives the other side of that identification. Contractual information then anchors the arrangement in an agreement, with its parties and its terms, rather than in a relationship described from memory. Service and function information explains the substance: what the provider supplies, in terms a non-technical reader can follow, and which functions would be affected if it stopped.

Data and location information completes the picture by recording what kind of data the service touches and where the relevant activity takes place. That part is often treated as an administrative extra, but it shapes supervisory questions about concentration, about movement of data, and about which authorities may have an interest. None of these fields is useful in isolation. The value lies in the links between them, and a quality check that only counts rows will miss a register full of unlinked facts. The guide on quality checks therefore tests links, not just presence.

Grey areas tend to cluster around three situations. The first is bundled services, where one contract covers several ICT services that support different functions. Recording the bundle as a single line hides the separate dependencies inside it, so the register should break the bundle down to the level at which a failure would actually be felt. The second is internal group provision, where a group company supplies ICT services to the entity. Group arrangements still need recording, and the group guide explains how to handle them without double counting or omission.

A practical test is to choose a business function, such as processing customer payments or handling insurance claims, and walk it through the register. Every ICT service that function needs should appear, with its provider and contract. Then reverse the walk: choose a provider and list every function that depends on it. If either walk hits a dead end, the register has a gap, even if the total number of entries looks impressive. A second test is to compare the register against contracts and invoices for a sample of arrangements. Entries with no contract behind them, and contracts with no entry, both deserve an explanation.

Completeness is therefore not a feeling but a checkable property. It improves when the register owner has a defined source for new arrangements, such as a procurement or contract approval step that feeds the register before a service goes live. It weakens when teams can start using a service without that step. The rest of this cluster builds on that insight: the content guides define what to record, and the process guides define how to keep the record honest.