FCA and PRA Mapping in the UK

Under the UK regime, mapping means tracing, for each important business service, the resources that support it and the dependencies between them, so that the firm can see what would have to keep working, or be restored, for the service to remain within its impact tolerance. The map covers people, processes, technology, facilities and third parties, and it follows the service end to end, from the channel a user touches through to the settlement, data store or record that completes the service. A map that stops at the firm boundary, or that lists systems without showing how they connect to the service, does not meet the purpose of the exercise, because the failure that stops a service often sits in a dependency that was never drawn.

Mapping is therefore a detective exercise rather than a diagramming exercise. It requires conversations with the people who operate the service, checks against incident history, and attention to informal workarounds that keep a service running but appear nowhere in formal documentation. A map built only from architecture documents will show the designed service, while a map built from operational knowledge will show the service as it actually runs, including the supplier, the manual step and the single specialist whose absence would stall recovery.

A UK map belongs to a service, not to a firm in general. Each important business service has its own map, even where services share technology, because sharing is itself a dependency worth seeing. For a claims handling service, for example, the map would include the customer channel, the claims system, the document store, the payment step, the teams that assess and approve claims, the facilities from which those teams work, and any supplier that provides a part of the chain. Omitting any element leaves a gap through which disruption can enter unseen.

A credible map is built by walking the service with the people who run it, step by step, and asking at each step what the step needs in order to function. That walk surfaces dependencies that formal documents miss, such as a spreadsheet maintained by one team, a data feed that arrives through an informal route, or a manual check that only certain staff know how to perform. Incident records are a useful cross check, because past failures reveal dependencies that were previously invisible. If an incident stopped a service through a route the map did not show, the map was incomplete, and the incident is evidence for correcting it.

Consider a mortgage servicing service. A walk through the service might start with the customer portal, move through the servicing system and the payment collection step, and end with the ledger and the regulatory reporting output. Along the way, the walk might reveal that payment collection depends on a single data feed, that the portal depends on an authentication service provided externally, and that a manual reconciliation step depends on a small team with specialist knowledge. Each of those findings changes how the service is understood, because each is a point where failure could stop the service or corrupt its outputs.

Mapping commonly fails at boundaries. It may stop at the edge of a department, so that a dependency owned by another team is omitted. It may stop at the firm boundary, so that a supplier dependency is noted only as a contract rather than as an operational link. It may omit people altogether, treating a service as if it were purely technological, even though recovery depends on staff who know the service, can operate workarounds and can make decisions under pressure. It may also omit facilities, on the assumption that remote working removes location dependence, even where specialist equipment or secure access remains location bound.

A map can be judged by whether it covers people, processes, technology, facilities and third parties for a named service, whether it shows dependencies between those elements rather than merely listing them, and whether it has been tested through scenario work or incidents. A map that has survived a scenario exercise, with gaps corrected as a result, carries more weight than a map that has only been reviewed on paper. A map that cannot explain a past incident, because the failure route is absent from it, needs correction before it is relied upon again.

Mapping connects directly to the other elements of the UK regime. Without a map, a tolerance cannot be tested meaningfully, because the firm cannot say what would fail or how recovery would proceed. Without a map, a self-assessment cannot describe vulnerabilities accurately, because the vulnerabilities sit in dependencies. The supporting guides on tolerances, scenario testing and self-assessment each assume a map exists, and each will expose, in its own way, whether that assumption holds.