Mapping Across a Group
Mapping across a group traces a service that spans entities, shared platforms and central teams, so a failure in one part is not mistaken for a local problem.
The short answer
Mapping across a group means tracing a service that is delivered by more than one entity within the same group, using shared platforms, central teams, or services provided from one entity to another. A customer may experience one service, but behind it there may be a subsidiary that operates the channel, a central technology function that runs the platform, and another entity that holds the data. The map must show those group relationships, who owns each part, and how recovery is coordinated across entities. Without that view, each entity may respond to its own fragment of an incident while nobody owns the service as a whole.
Why is group mapping different?
Group mapping differs because ownership, accountability, and recovery do not sit in one place. A service owner in one entity may depend on a platform owned by a central function, which in turn depends on a supplier contracted by another entity. Decision rights, incident communication, and recovery sequencing must therefore cross entity boundaries, and they may be governed by internal arrangements rather than external contracts. The map should record those internal arrangements in the same way it records external suppliers: what is provided, by whom, to which service, and under what terms. Treating group provision as informal or automatic is a common error, because informality collapses under incident pressure.
What should the group map show?
For each part of the service, the map should show the entity that provides it, the entity that receives it, and the team and owner on each side. It should show shared platforms and their users, so that a platform failure can be traced to every service it affects across the group. It should also show where a group service is itself dependent on an external supplier, because that external dependency may be shared by several group entities without any of them realising it. The map is therefore both a service trace and a group picture: it follows one service across entities, and it reveals where group-wide concentration creates group-wide risk.
How do entities coordinate in a disruption?
Coordination needs to be agreed before an incident, not improvised during one. The map should support that agreement by showing who declares an incident for the service as a whole, who communicates with customers, who decides on workarounds that affect other entities, and how recovery is sequenced when several services compete for the same shared platform. A rehearsal that involves all relevant entities is the best test of that coordination. If the rehearsal shows that each entity waits for another to act, or that customer communication is duplicated or delayed, the map has exposed a governance gap, and that gap should be owned at group level rather than left to individual entities.
What about differences between entities?
Entities within a group may operate under different regimes, different systems, or different local arrangements, even when they contribute to the same service. The map should label those differences rather than smoothing them over. A process that is standard in one entity may be manual in another. A system that is hosted centrally may have a local fallback in one location but not in another. Recording those variations matters, because a recovery plan that assumes uniformity will fail where the service is actually varied. The map should therefore be specific about where the service is common across the group and where it diverges, entity by entity.
How is group mapping kept current?
Group maps go stale when entities change independently. One entity may replace a system, another may reorganise a team, and the central platform may be upgraded, all without a single view of the combined effect. Currency therefore requires a group-level check, not only entity-level updates. Changes that affect a shared platform or a cross-entity service should trigger a review of the group map, with the affected entities confirming their parts. Under DORA in the EU and under FCA and PRA policy in the UK, group and outsourcing arrangements are addressed in their own terms, labelled separately in these guides, and a group map that is jointly owned and jointly tested is the practical way to show that the service, not just its fragments, is understood.
Primary sources on the record
- Regulation (EU) 2022/2554, Official Journal text on EUR-Lex.
- FCA operational resilience, FCA operational resilience pages.
- NIST CSRC, NIST Computer Security Resource Center.
Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.