Register ICT Services and Functions

This part of the register describes what a provider does and what the entity does with it. The ICT service is the technology supplied, such as hosting, a payments platform, a data feed, or a customer communications system. The function is the business activity that depends on that service, such as taking payments, settling trades, handling claims, or serving customers online. Recording both sides, and the link between them, is what turns a list of suppliers into a dependency map. A service with no linked function looks harmless. A function with no recorded service looks self-sufficient. Both impressions are misleading, and both fail in a disruption.

Good service and function entries use plain language first and technical labels second. A supervisor, a risk manager, and an incident responder should all be able to read the entry and picture the same thing. This guide explains how to describe services at the right level of detail, how to link them to functions without overcomplicating the map, and how to handle services that support many functions or functions that depend on many services.

A good service description answers three questions in ordinary words: what does the service do, for whom inside the entity, and what would stop if it stopped. Technical product names alone rarely answer those questions, because the same product can be used in very different ways by different firms. A cloud platform might host a customer portal for one entity and a risk calculation engine for another, and the operational consequences of failure differ sharply. The description should therefore reflect the entity's actual use, not the provider's marketing description.

Function linkage is where the register connects technology to the business. Each service entry should name the functions it supports, using function names the business itself recognises. A payments function, a lending function, a trading function, and a claims function are all more useful than generic labels, because they let readers judge impact. When a service supports several functions, all of them should be listed. Omitting a secondary function creates a blind spot: the incident team may restore the main function and discover too late that a smaller, still important function remains down.

The reverse linkage matters equally. For each important function, the register should allow a reader to list every ICT service it depends on. That view reveals concentration within a function, such as several steps of a customer journey depending on the same provider, and it reveals single points of failure that a provider-by-provider view would miss. Building both views takes care at entry time, but it pays off whenever the entity tests recovery, plans a migration, or answers a supervisor's question about what a provider failure would actually interrupt.

Not every service matters equally, and the register should reflect that difference without inventing a scoring system that DORA does not prescribe. Importance can be shown qualitatively: by naming the functions supported, by describing the customer or market impact of a stoppage, and by noting whether an alternative exists or the service is the only route. A service that supports a customer-facing function with no ready alternative reads very differently from a service that supports an internal reporting tool with a manual workaround, and the register entries should make that difference plain in words.

Service and function maps decay when new tools are adopted without a register entry, or when a function migrates to a new platform while the old entry lingers. The antidote is to tie register updates to service changes: a new ICT service should not go live for a business function until its register entry exists, and a migration should update both the old and the new entries at the time of the move. Those steps sound administrative, but they protect the incident team, which relies on the map under pressure and cannot afford to discover an unrecorded dependency during a live disruption.

Periodic walk-throughs help as well. Taking one function at a time and tracing it through the register, the architecture diagrams, and the teams that run it will surface mismatches that a row-count check would miss. The walk-through can be short, and it can rotate across functions over time, so the whole map is tested without a single exhausting review. When the walk-through and the register agree, the entity has something valuable: a dependency map it can defend, a supervisor can follow, and an incident team can actually use.