Register for Groups and Branches

Groups and branches complicate the register because technology is often shared while accountability stays with individual entities. A group may negotiate one contract, run one platform, and supply it to several entities, while branches use a mix of group services and local providers. The register must reflect that reality without merging entities together and without losing local arrangements. Each entity's register should show what that entity uses, whether the provider is external, a group company, or a local supplier engaged by a branch, and it should show the arrangement in a way that a supervisor can follow from entity to provider without confusion.

This guide explains the patterns that cause trouble, the attribution rules that prevent double counting and omission, and the coordination habits that keep group and branch registers consistent. The underlying principle is the one from the entity guide, applied to a harder structure: attribute each arrangement to the entity that uses the service, and record sharing as a fact about that arrangement, not as a reason to blur entities.

A shared group service, such as a group platform or a group data service supplied to several entities, should appear in each using entity's register, because each entity depends on it. That repetition is not duplication. Duplication would be recording the same entity's use several times. Recording the same group service across different entities reflects real dependence in each of them, and it lets each entity's supervisor see the exposure of the firm they supervise. The entry in each register should describe the service as that entity uses it, and should identify the group provider clearly, so the shared nature of the service is visible.

Branches create three common patterns. In the first, the branch uses only group or head office arrangements, with no local ICT providers of its own. That pattern is simple to record, provided the register states it clearly rather than leaving branch coverage ambiguous. In the second, the branch uses a mix: group services for core systems and local providers for local needs, such as local connectivity or local customer channels. Both layers must appear, with local arrangements attributed to the entity and identified as branch-used where the template allows.

In the third pattern, a branch engages a provider that the head office does not use, or uses a group service in a different configuration. That pattern is the easiest to miss, because branch procurement may sit outside central processes. The remedy, described in the entity guide, is a notification route from branches to the register owner, backed by periodic branch confirmation. Without that route, the register will describe the head office accurately and the branches incompletely, and a supervisor or incident team relying on it will be misled about part of the business.

Double counting and omission are opposite errors with the same cause: unclear attribution rules. Double counting happens when one entity's arrangement is entered multiple times, for example once for the head office and once for each branch, as if each were a separate arrangement. Omission happens when an arrangement is assumed to sit in another entity's register, or in a group register, and therefore appears in none. A clear rule prevents both: each arrangement is recorded once per using entity, with branch use shown within that entity's record, and group sharing shown as a property of the arrangement rather than as a separate register entry.

Group changes, such as acquisitions, disposals, restructurings, and new branches, should trigger register reviews for every affected entity. An acquisition may bring new ICT arrangements into an entity's register, or new entities into a group sharing pattern. A disposal may remove arrangements, or leave an entity dependent on a former group provider under a new commercial arrangement. A branch closure may end local arrangements but leave group arrangements untouched. Each of those events changes the register, and the change should be recorded when the corporate event happens, not discovered at the next reporting cycle.

The practical habit is to link register review to corporate change processes, so the team handling a restructuring notifies register owners as a matter of routine. That link is easy to state and easy to forget, which is why it should be written into the change process rather than left to individual diligence. When group and branch registers reflect corporate reality promptly, supervisors can follow dependence across the group, entities can plan exits and continuity with a true picture, and the register fulfils its purpose for the most complex structures it is meant to describe.