Register Entity and Branch Information

Entity and branch information answers the most basic register question: whose arrangements are these. The register is kept at entity level, which means each financial entity in scope has its own record of its own ICT third-party arrangements. The entry must identify the entity clearly enough that a supervisor, or another reader, can match it to the supervised firm without guessing, and it must show how branches fit in, so arrangements used through a branch are neither omitted nor counted as if they belonged to a different entity. Without that anchor, every later field floats. A provider, a contract, and a function mean little if the reader cannot tell which legal entity relies on them.

This guide explains what that anchor contains, why branches need explicit treatment, and which mistakes recur when entity information is copied carelessly between group members. The theme is attribution. Every arrangement in the register should be traceable to the entity that uses the service and bears the operational risk if it fails, even when a group function negotiated the contract or a branch uses the service day to day.

DORA supervision is organised around entities, and operational risk ultimately sits with the entity that provides the financial service. A group may share technology, but the customer relationship, the regulatory permissions, and the accountability for continuity belong to specific entities within that group. Keeping the register at entity level respects that structure. It prevents a group-level summary from blurring which entity depends on which provider, and it lets a competent authority see the position of the firm it supervises without untangling a group-wide list.

Identification needs stable, distinguishing details rather than a familiar trading name. Group structures often reuse similar names across subsidiaries, and a short name that staff recognise internally may be ambiguous to a supervisor reading many registers. The register should therefore use the formal identity of the entity, together with any identifier the applicable template requires, so the record can be matched reliably to supervisory records. Where the entity operates through branches, the register should make the branch structure visible instead of folding branch use silently into the head office entry.

That visibility matters because branches can change the risk picture. A branch may use a local provider for part of its service, rely on the head office arrangement for the rest, or serve customers in a different market under the same system. If the register does not distinguish those patterns, a reader may assume a single uniform arrangement where several exist, or miss a local dependency altogether. The aim is not bureaucratic detail for its own sake. It is a map that matches how the entity actually operates, branch by branch, where that distinction affects the service.

One recurring mistake is duplication, where the same arrangement is entered separately for the head office and for each branch as if each were a separate contract, inflating the apparent number of providers. The opposite mistake is omission, where branch-only arrangements never reach the register because branch procurement sits outside the central process. A third mistake is misattribution, where an arrangement used by one entity is recorded under a sister entity because a group team negotiated it. Each mistake distorts a different supervisory question: duplication exaggerates concentration, omission hides dependence, and misattribution points follow-up at the wrong firm.

Entity information changes less often than service information, which makes it easy to neglect. Mergers, restructurings, new branches, branch closures, and changes of legal name all alter the anchor, and each should trigger a register review even if no provider has changed. The trigger should sit with the team that handles corporate changes, not with the register owner alone, because the register owner may not hear about a restructuring until long after it happens. A short notification step, built into the corporate change process, closes that gap.

A final check is worth building into every reporting cycle: read the entity and branch section as a stranger would. Does it identify one entity unambiguously. Does it explain branch coverage in a way that matches how the business is organised today. Could a supervisor match each arrangement to the entity that uses it. If any answer is uncertain, the fix belongs before the report is sent, not after a supervisor asks. Entity information is the smallest part of the register, but it frames everything else, and a weak frame undermines a strong set of entries.