Third-Party Risk Registers

A third-party risk register is a structured record of the ICT providers an entity depends on, the services those providers support, the risks attached to each dependency, and the controls and owners that manage them. Under DORA, the register is a working tool rather than an administrative list. It should let the entity answer, at any moment, which services depend on which providers, which providers are most important, what subcontractors sit behind them, and what would happen if a provider failed. A register that is out of date, incomplete, or disconnected from services may look tidy, yet it will mislead precisely when it is needed most, during an incident or an exit.

A wealth management illustration explains the link. Listing a platform provider without naming the services it supports, such as portfolio management, client reporting or trading, tells the entity little about impact. Linking each provider to the services it supports, and each service to its tolerance and its owner, turns a vendor list into a risk picture. When a provider reports an incident, the entity can then trace the impact immediately, rather than working out afterwards which services might be affected. That traceability is the register's main value, and it is lost whenever providers are recorded without their service connections.

A useful entry records the provider and the function it performs, the services supported, the data and systems involved in general terms, the contract and its key rights, subcontractors that support the service, the assessed importance of the dependency, the owner responsible for oversight, and the main risks and mitigations. Not every entry needs the same depth: a routine tool warrants a lighter entry than a provider supporting an important service. Depth should follow importance, so that effort goes where failure would matter most. An entry that tries to record everything for every provider will quickly become unmaintainable, and an unmaintainable register soon becomes an inaccurate one.

A register stays current only if updating it is part of ordinary change, not a separate annual exercise. New providers should enter the register when they are selected, entries should change when contracts, subcontractors or services change, and entries should be removed or archived when a provider leaves. Oversight meetings, contract renewals and incident reviews are natural moments to check entries, because the people in those discussions already hold the relevant facts. Assigning an owner for the register as a whole, and owners for individual entries, prevents the common outcome where everyone assumes someone else has updated it.

In practice, the register supports several activities at once. Oversight teams use it to prioritise which providers need deeper attention. Incident teams use it to trace impact and to find contract rights and contacts quickly. Exit planners use it to understand what must move and what knowledge must transfer. Senior management uses it to see concentration, such as several services depending on one provider, that would otherwise remain hidden in separate contracts. A register that serves only one of those purposes is underused; a register that serves all of them earns the effort of keeping it current.

A register becomes misleading when completeness is prized over accuracy. Entries copied from old contracts, providers recorded under outdated names, subcontractors never updated, and risks described in generic terms all create a false picture. Quality checks help: sampling entries against contracts and service maps, checking that owners still hold their roles, and asking whether an incident team could use the entry without further research. Those checks take time, but they are cheaper than discovering during a real incident that the register describes arrangements that no longer exist. The register's credibility depends on its accuracy, not on its length. A register that passes such checks can be trusted in a crisis, while one that fails them should be treated as a work in progress.